[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-10 08:04 --- New patch at http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00864.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug c++/20401] New: error message is misleading
The error message in this case is misleading:
$ cat foo.cc
#include
namespace foo {
typedef long long offset_t;
}
using namespace std;
using namespace foo;
int main() {
offset_t fpos;
}
$
$ g++ -c foo.cc
foo.cc: In function `int main()':
foo.cc:11: error: `offset_t' undeclared (first use this function)
foo.cc:11: error: (Each undeclared identifier is reported only once for each
function it appears in.)
foo.cc:11: error: parse error before `;' token
$
Actually 'offset_t' is declared twice, once in the global namespace in Solaris'
and once in the foo namespace.
--
Summary: error message is misleading
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: papadopo at shfj dot cea dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20401
[Bug c++/20401] error message is misleading
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-03-10 09:48 --- Created an attachment (id=8371) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8371&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20401
[Bug c++/20401] error message is misleading
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-03-10 09:49 --- Created an attachment (id=8372) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8372&action=view) stripped down test case -- What|Removed |Added Attachment #8371 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20401
[Bug java/20338] Program compiled with gcj crashes when accessing private static method from nested class
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-10 11:00 --- While the main problem reported by the filer has now been fixed on mainline, I think we should not close this PR just yet - not until we check in a testcase for our testsuite for this, which is not possible till PR19870 is fixed. Otherwise, we can close this one and add a note to PR19870 to remember to add in the testcase for this PR when that is fixed. -- What|Removed |Added BugsThisDependsOn||19870 Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20338
[Bug target/18668] use prescott's fisttp
--- Additional Comments From uros at kss-loka dot si 2005-03-10 11:01 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01009.html -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si |dot org | Status|NEW |ASSIGNED Last reconfirmed|2004-11-29 14:27:29 |2005-03-10 11:01:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18668
[Bug java/20338] Program compiled with gcj crashes when accessing private static method from nested class
--- Additional Comments From mckinlay at redhat dot com 2005-03-10 11:30 --- Why not check in the test case and XFAIL it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20338
[Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-10
11:44 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Mar 9, 2005, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 09, 2005 at 01:02:08AM -0300, Alexandre Oliva wrote:
>> On Mar 8, 2005, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
>>
>> > Unfortunately, it seems to break ada bootstrap on at least x86-64 and i386:
>>
>> Odd... It surely completed bootstrap for me with default build flags.
> Your code hits just once on ali.adb
Rats, I didn't realize I needed --enable-languages=all,ada to pick
that up. Fixed now.
> Note that recog_memoized (v->insn) is -1 even without the change,
> not sure what would fix that up.
Problem is that the insn has a volatile memory access, and loop runs
with volatile_ok = 0.
I'm not entirely sure why that is; presumably to avoid introducing or
removing volatile memory accesses. I can see how this prevents
introducing them, but it appears to me that it still can remove them.
Anyhow, I've come up with a solution for this. This patch introduces
a new function that is like validate_change, but if validate_change
fails and the original insn fails to be recognized with !volatile_ok
but passes with volatile_ok, then try the change and recog with
volatile_ok.
> But it certainly shows that *v->location doesn't have to be
> a simple pseudo, so gen_move_insn might not work.
Indeed. I've introduced a new pseudo to hold the computed value now,
for the case in which *v->location isn't a reg.
Passed bootstrap and regtest on x86_64-linux-gnu on mainline, as well
as bootstrap on gcc-4_0-rhl-branch, both with Ada enabled. Ok to
install?
Index: gcc/ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
PR target/20126
* loop.c (loop_givs_rescan): If replacement of DEST_ADDR failed,
set the original address pseudo to the correct value before the
original insn, if possible, and leave the insn alone, otherwise
create a new pseudo, set it and replace it in the insn.
* recog.c (validate_change_maybe_volatile): New.
* recog.h (validate_change_maybe_volatile): Declare.
Index: gcc/loop.c
===
RCS file: /cvs/gcc/gcc/gcc/loop.c,v
retrieving revision 1.522
diff -u -p -r1.522 loop.c
--- gcc/loop.c 17 Jan 2005 08:46:15 - 1.522
+++ gcc/loop.c 10 Mar 2005 11:23:59 -
@@ -5470,9 +5470,31 @@ loop_givs_rescan (struct loop *loop, str
mark_reg_pointer (v->new_reg, 0);
if (v->giv_type == DEST_ADDR)
- /* Store reduced reg as the address in the memref where we found
- this giv. */
- validate_change (v->insn, v->location, v->new_reg, 0);
+ {
+ /* Store reduced reg as the address in the memref where we found
+this giv. */
+ if (validate_change_maybe_volatile (v->insn, v->location,
+ v->new_reg))
+ /* Yay, it worked! */;
+ /* Not replaceable; emit an insn to set the original
+giv reg from the reduced giv. */
+ else if (REG_P (*v->location))
+ loop_insn_emit_before (loop, 0, v->insn,
+ gen_move_insn (*v->location,
+ v->new_reg));
+ else
+ {
+ /* If it wasn't a reg, create a pseudo and use that. */
+ rtx reg, seq;
+ start_sequence ();
+ reg = force_reg (v->mode, *v->location);
+ seq = get_insns ();
+ end_sequence ();
+ loop_insn_emit_before (loop, 0, v->insn, seq);
+ gcc_assert (validate_change_maybe_volatile (v->insn, v->location,
+ reg));
+ }
+ }
else if (v->replaceable)
{
reg_map[REGNO (v->dest_reg)] = v->new_reg;
Index: gcc/recog.c
===
RCS file: /cvs/gcc/gcc/gcc/recog.c,v
retrieving revision 1.221
diff -u -p -r1.221 recog.c
--- gcc/recog.c 7 Mar 2005 13:52:08 - 1.221
+++ gcc/recog.c 10 Mar 2005 11:24:01 -
@@ -235,6 +235,34 @@ validate_change (rtx object, rtx *loc, r
return apply_change_group ();
}
+/* Same as validate_change, but doesn't support groups, and it accepts
+ volatile mems if they're already present in the original insn.
+
+ ??? Should this should search new for new volatile MEMs and reject
+ them? */
+
+int
+validate_change_maybe_volatile (rtx object, rtx *loc, rtx new)
+{
+ int result;
+
+ if (validate_change (object, loc, new, 0))
+return 1;
+
+ if (volatile_ok || ! insn_invalid_p (object))
+return 0;
+
+ volatile_ok = 1;
+
+ gcc_assert (! insn_invalid_p (object));
+
+ result = validate_change (object, loc, new, 0);
+
+ volatile_ok = 0;
+
+ return result;
+}
+
/* This subroutine of apply_cha
[Bug java/20338] Program compiled with gcj crashes when accessing private static method from nested class
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-10 12:00 --- (In reply to comment #7) > Why not check in the test case and XFAIL it? I feel dumb for not having thought of it myself... I am closing this bug and will submit the testcase as a separate patch. Thanks. -- What|Removed |Added BugsThisDependsOn|19870 | Status|SUSPENDED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20338
GCC segmentation fault
Hello!
I am NOT sure that we discovered problem the first... but this makes
GCC3.0.4-2 dump core 100%
Host ARCH i386 target ARCH i386
std::string str;
make_pair("string",(str.length() == 0?throw "string":str));
/usr/include/g++-v3/bits/stl_pair.h:222: Internal error: Segmentation fault
Regards,
Alexandre.
[Bug c/20402] New: gcc.dg/noncompile/920923-1.c ICE
I noticed that latest CVS (20050310) silently ICEs (reporting PASS) on testcase
gcc.dg/noncompile/920923-1.c. Reduced to:
struct *A a;
# gcc -v ./a.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++
--enable-threads=posix --enable-share
Thread model: posix
gcc version 4.1.0 20050310 (experimental)
/usr/local/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1 -quiet -v ./a.c -quiet
-dumpbase a.c -mtune=pentiumpro -auxbase a -version -o /tmp/ccFGmSSx.s
ignoring nonexistent directory "NONE/include"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/include
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/include
End of search list.
GNU C version 4.1.0 20050310 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20050310 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
./a.c:1: error: expected '{' before '*' token
./a.c:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: gcc.dg/noncompile/920923-1.c ICE
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot dvorak at kraxnet dot cz
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=20402
[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of "goto *"
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-10 12:48 --- > Maybe there should be another combining pass after the duplication > of the indirect jumps. Should I create another PR for this? There should not be another "combining" pass (you really mean constant propagation). This new unfactoring stuff runs after register allocation, so such a pass would not really help, except maybe to make the code look prettier to you. But, is this: mov0xfffc(%ebx),%eax jmp*%eax slower than this: jmp*0xfffc(%ebx) or have you not tried that (e.g. by hacking the assembly by hand)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug target/20400] C++ std::queue conflicts with C header 'struct queue'
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 12:59 --- This is why standard C++ classes are in namespaces. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20400
[Bug c/20402] [4.1 Regression] gcc.dg/noncompile/920923-1.c ICE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 13:06 --- Confirmed, caused by the new parser. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org, jsm28 at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||error-recovery, ice-on- ||invalid-code Last reconfirmed|-00-00 00:00:00 |2005-03-10 13:06:22 date|| Summary|gcc.dg/noncompile/920923-1.c|[4.1 Regression] |ICE |gcc.dg/noncompile/920923-1.c ||ICE Target Milestone|--- |4.1.0 Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20402
[Bug debug/20403] New: dwarf2: DW_MACINFO_define - wrong lineno fields for predefined macros
* the options given when GCC was configured/built;
Configured with:
/home/niva/svnwork/gccvendorcurrent/configure
--with-headers=/home/niva/oc2000/mips/src/include
--without-libs --enable-generated-files-in-srcdir --enable-threads=posix
-with-dwarf2
--disable-shared --target=mips64-none-elf --verbose --enable-languages=c
--srcdir=/home/niva/svnwork/gccvendorcurrent --prefix=/home/niva/local
--enable-cpp
* the complete command line that triggers the bug;
mips64-none-elf-gcc -v -g3 -c -o macros.o macros.c -DMYMACRO="123456" -UTTT
-save-temps
mips64-none-elf-readelf --debug-dump=macro macros.o
* the compiler output (error messages, warnings, etc.);
No error messages
* There are wrong line numbers in the DW_MACINFO_define and
DW_MACINFO_undef directives for pre(defined/undefined) macros.
According to the document "DWARF Debugging Information Format",
Version 3 November 12, 2003 (Draft 9), see
6.3.3 Macinfo entries for Command Line Options,
"All such DW_MACINFO_define and DW_MACINFO_undef entries
representing compilation options ... should encode the value 0 as
their line number operand."
But readelf reports the lineno values 1, 2, 3, ... , etc.
for the and DW_MACINFO_define and
DW_MACINFO_undef entries.
* the preprocessed file (*macro.i*)
# 1 "macros.c"
# 1 "/home/niva/tests/from_kost/debug1//"
# 1 ""
#define __STDC_HOSTED__ 1
#define __GNUC__ 3
#define __GNUC_MINOR__ 4
#define __GNUC_PATCHLEVEL__ 3
#define __SIZE_TYPE__ unsigned int
#define __PTRDIFF_TYPE__ int
#define __WCHAR_TYPE__ int
#define __WINT_TYPE__ unsigned int
#define __GXX_ABI_VERSION 1002
#define __SCHAR_MAX__ 127
#define __SHRT_MAX__ 32767
#define __INT_MAX__ 2147483647
#define __LONG_MAX__ 2147483647L
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __WCHAR_MAX__ 2147483647
#define __CHAR_BIT__ 8
#define __FLT_EVAL_METHOD__ 0
#define __FLT_RADIX__ 2
#define __FLT_MANT_DIG__ 24
#define __FLT_DIG__ 6
#define __FLT_MIN_EXP__ (-125)
#define __FLT_MIN_10_EXP__ (-37)
#define __FLT_MAX_EXP__ 128
#define __FLT_MAX_10_EXP__ 38
#define __FLT_MAX__ 3.40282347e+38F
#define __FLT_MIN__ 1.17549435e-38F
#define __FLT_EPSILON__ 1.19209290e-7F
#define __FLT_DENORM_MIN__ 1.40129846e-45F
#define __FLT_HAS_INFINITY__ 1
#define __FLT_HAS_QUIET_NAN__ 1
#define __DBL_MANT_DIG__ 53
#define __DBL_DIG__ 15
#define __DBL_MIN_EXP__ (-1021)
#define __DBL_MIN_10_EXP__ (-307)
#define __DBL_MAX_EXP__ 1024
#define __DBL_MAX_10_EXP__ 308
#define __DBL_MAX__ 1.7976931348623157e+308
#define __DBL_MIN__ 2.2250738585072014e-308
#define __DBL_EPSILON__ 2.2204460492503131e-16
#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
#define __DBL_HAS_INFINITY__ 1
#define __DBL_HAS_QUIET_NAN__ 1
#define __LDBL_MANT_DIG__ 53
#define __LDBL_DIG__ 15
#define __LDBL_MIN_EXP__ (-1021)
#define __LDBL_MIN_10_EXP__ (-307)
#define __LDBL_MAX_EXP__ 1024
#define __LDBL_MAX_10_EXP__ 308
#define __DECIMAL_DIG__ 17
#define __LDBL_MAX__ 1.7976931348623157e+308L
#define __LDBL_MIN__ 2.2250738585072014e-308L
#define __LDBL_EPSILON__ 2.2204460492503131e-16L
#define __LDBL_DENORM_MIN__ 4.9406564584124654e-324L
#define __LDBL_HAS_INFINITY__ 1
#define __LDBL_HAS_QUIET_NAN__ 1
#define __REGISTER_PREFIX__
#define __USER_LABEL_PREFIX__
#define __VERSION__ "3.4.3"
#define __NO_INLINE__ 1
#define __FINITE_MATH_ONLY__ 0
#define __mips__ 1
#define _mips 1
#define mips 1
#define __mips64 1
#define __R4000 1
#define __R4000__ 1
#define R4000 1
#define _R4000 1
#define __mips_fpr 64
#define _MIPS_ARCH_MIPS3 1
#define _MIPS_ARCH "mips3"
#define _MIPS_TUNE_MIPS3 1
#define _MIPS_TUNE "mips3"
#define __mips 3
#define _MIPS_ISA _MIPS_ISA_MIPS3
#define __mips_hard_float 1
#define __MIPSEB 1
#define __MIPSEB__ 1
#define MIPSEB 1
#define _MIPSEB 1
#define __LANGUAGE_C 1
#define __LANGUAGE_C__ 1
#define LANGUAGE_C 1
#define _LANGUAGE_C 1
# 1 ""
#define MYMACRO 123456
#undef TTT
# 1 "macros.c"
#define max(x,y) ((x) >= (y) ? (x) : (y))
#define min(x,y) ((x) <= (y) ? (x) : (y))
int main ()
{
int i = 6, k = 7;
return ((i) <= (k) ? (i) : (k)) + ((i) >= (k) ? (i) : (k));
}
* The output of "mips64-none-elf-readelf --debug-dump=macro macros.o":
DW_MACINFO_define - lineno : 1 macro : __STDC_HOSTED__ 1
DW_MACINFO_define - lineno : 2 macro : __GNUC__ 3
DW_MACINFO_define - lineno : 3 macro : __GNUC_MINOR__ 4
DW_MACINFO_define - lineno : 4 macro : __GNUC_PATCHLEVEL__ 3
DW_MACINFO_define - lineno : 5 macro : __SIZE_TYPE__ unsigned int
DW_MACINFO_define - lineno : 6 macro : __PTRDIFF_TYPE__ int
DW_MACINFO_define - lineno : 7 macro : __WCHAR_TYPE__ int
DW_MACINFO_define - lineno : 8 macro : __WINT_TYPE__ unsigned int
DW_MACINFO_define - lineno : 9 macro : __GXX_ABI_VERSION 1002
DW_MACINFO_define - lineno : 10 macro : __SCHAR_MAX__ 127
DW_MACINFO_define - lineno : 11 macro : __SHRT_MAX__ 32767
DW_MACINFO_define - lineno : 12 macro : __INT_MAX__ 2147483647
DW_MACINFO_define - line
[Bug java/20394] Can't run db2 jdbc application compiled with gcj
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 13:10 --- Closing as this is not our bug. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20394
[Bug debug/20404] New: dwarf2: no DW_MACINFO_start_file for the "base" source file
* the options given when GCC was configured/built;
Configured with:
/home/niva/svnwork/gccvendorcurrent/configure
--with-headers=/home/niva/oc2000/mips/src/include
--without-libs --enable-generated-files-in-srcdir --enable-threads=posix
-with-dwarf2
--disable-shared --target=mips64-none-elf --verbose --enable-languages=c
--srcdir=/home/niva/svnwork/gccvendorcurrent --prefix=/home/niva/local
--enable-cpp
* the complete command line that triggers the bug;
mips64-none-elf-gcc -v -g3 -c -o macros.o macros1.c -DMYMACRO="123456" -UTTT
mips64-none-elf-readelf --debug-dump=macro macros1.o
* the compiler output (error messages, warnings, etc.);
No error messages
* There is no DW_MACRO_start_file for the "base" source file
submitted to the compiler for compilation.
According to the document "DWARF Debugging Information Format",
Version 3 November 12, 2003 (Draft 9), see
6.3.2 Base Source Entries,
"In addition to producing a matched pair of DW_MACRO_start_file
and DW_MACRO_end_file entries for each inclusion directive
actually processed during compilation, A PRODUCER SHOULD GENERATE
SUCH A MATCHED PAIR ALSO FOR THE "BASE" SOURCE FILE SUBMITTED TO
THE COMPILER FOR COMPILATION."
But readelf does not show a DW_MACRO_start_file for the "base"
source file.
* NOTE: gcc-3.2.2 GENERATED the DW_MACRO_start_file entry for the
"base" source file.
* the preprocessed file (*.i*)
# 1 "macros1.c"
# 1 "/home/niva/tests/from_kost/debug1//"
# 1 ""
#define __STDC_HOSTED__ 1
#define __GNUC__ 3
#define __GNUC_MINOR__ 4
#define __GNUC_PATCHLEVEL__ 3
#define __SIZE_TYPE__ unsigned int
#define __PTRDIFF_TYPE__ int
#define __WCHAR_TYPE__ int
#define __WINT_TYPE__ unsigned int
#define __GXX_ABI_VERSION 1002
#define __SCHAR_MAX__ 127
#define __SHRT_MAX__ 32767
#define __INT_MAX__ 2147483647
#define __LONG_MAX__ 2147483647L
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __WCHAR_MAX__ 2147483647
#define __CHAR_BIT__ 8
#define __FLT_EVAL_METHOD__ 0
#define __FLT_RADIX__ 2
#define __FLT_MANT_DIG__ 24
#define __FLT_DIG__ 6
#define __FLT_MIN_EXP__ (-125)
#define __FLT_MIN_10_EXP__ (-37)
#define __FLT_MAX_EXP__ 128
#define __FLT_MAX_10_EXP__ 38
#define __FLT_MAX__ 3.40282347e+38F
#define __FLT_MIN__ 1.17549435e-38F
#define __FLT_EPSILON__ 1.19209290e-7F
#define __FLT_DENORM_MIN__ 1.40129846e-45F
#define __FLT_HAS_INFINITY__ 1
#define __FLT_HAS_QUIET_NAN__ 1
#define __DBL_MANT_DIG__ 53
#define __DBL_DIG__ 15
#define __DBL_MIN_EXP__ (-1021)
#define __DBL_MIN_10_EXP__ (-307)
#define __DBL_MAX_EXP__ 1024
#define __DBL_MAX_10_EXP__ 308
#define __DBL_MAX__ 1.7976931348623157e+308
#define __DBL_MIN__ 2.2250738585072014e-308
#define __DBL_EPSILON__ 2.2204460492503131e-16
#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
#define __DBL_HAS_INFINITY__ 1
#define __DBL_HAS_QUIET_NAN__ 1
#define __LDBL_MANT_DIG__ 53
#define __LDBL_DIG__ 15
#define __LDBL_MIN_EXP__ (-1021)
#define __LDBL_MIN_10_EXP__ (-307)
#define __LDBL_MAX_EXP__ 1024
#define __LDBL_MAX_10_EXP__ 308
#define __DECIMAL_DIG__ 17
#define __LDBL_MAX__ 1.7976931348623157e+308L
#define __LDBL_MIN__ 2.2250738585072014e-308L
#define __LDBL_EPSILON__ 2.2204460492503131e-16L
#define __LDBL_DENORM_MIN__ 4.9406564584124654e-324L
#define __LDBL_HAS_INFINITY__ 1
#define __LDBL_HAS_QUIET_NAN__ 1
#define __REGISTER_PREFIX__
#define __USER_LABEL_PREFIX__
#define __VERSION__ "3.4.3"
#define __NO_INLINE__ 1
#define __FINITE_MATH_ONLY__ 0
#define __mips__ 1
#define _mips 1
#define mips 1
#define __mips64 1
#define __R4000 1
#define __R4000__ 1
#define R4000 1
#define _R4000 1
#define __mips_fpr 64
#define _MIPS_ARCH_MIPS3 1
#define _MIPS_ARCH "mips3"
#define _MIPS_TUNE_MIPS3 1
#define _MIPS_TUNE "mips3"
#define __mips 3
#define _MIPS_ISA _MIPS_ISA_MIPS3
#define __mips_hard_float 1
#define __MIPSEB 1
#define __MIPSEB__ 1
#define MIPSEB 1
#define _MIPSEB 1
#define __LANGUAGE_C 1
#define __LANGUAGE_C__ 1
#define LANGUAGE_C 1
#define _LANGUAGE_C 1
# 1 ""
#define MYMACRO 123456
#undef TTT
# 1 "macros1.c"
# 1 "macros.c" 1
#define max(x,y) ((x) >= (y) ? (x) : (y))
#define min(x,y) ((x) <= (y) ? (x) : (y))
int main ()
{
int i = 6, k = 7;
return ((i) <= (k) ? (i) : (k)) + ((i) >= (k) ? (i) : (k));
}
# 2 "macros1.c" 2
* The output of "mips64-none-elf-readelf --debug-dump=macro macros1.o":
Contents of the .debug_macinfo section:
DW_MACINFO_define - lineno : 1 macro : __STDC_HOSTED__ 1
DW_MACINFO_define - lineno : 2 macro : __GNUC__ 3
DW_MACINFO_define - lineno : 3 macro : __GNUC_MINOR__ 4
DW_MACINFO_define - lineno : 4 macro : __GNUC_PATCHLEVEL__ 3
DW_MACINFO_define - lineno : 5 macro : __SIZE_TYPE__ unsigned int
DW_MACINFO_define - lineno : 6 macro : __PTRDIFF_TYPE__ int
DW_MACINFO_define - lineno : 7 macro : __WCHAR_TYPE__ int
DW_MACINFO_define - lineno : 8 macro : __WINT_TYPE__ unsigned int
DW_MACINFO_define - lineno : 9 macro : __GXX_ABI_V
[Bug debug/20403] dwarf-3: DW_MACINFO_define - wrong lineno fields for predefined macros
-- What|Removed |Added Keywords||wrong-debug Summary|dwarf2: DW_MACINFO_define - |dwarf-3: DW_MACINFO_define - |wrong lineno fields for |wrong lineno fields for |predefined macros |predefined macros http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20403
[Bug debug/20404] dwarf2: no DW_MACINFO_start_file for the "base" source file
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 13:17 --- *** This bug has been marked as a duplicate of 20253 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20404
[Bug debug/20253] [3.4 regression]: Macro debug info broken due to lexer change
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 13:18 --- *** Bug 20404 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||niva at niisi dot msk dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20253
[Bug java/20312] No warning on bad method
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-10 13:30 --- A patch is here: http://gcc.gnu.org/ml/java-patches/2005-q1/msg00710.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20312
[Bug middle-end/20225] [4.0/4.1 regression] ICE during GC
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-10 13:37 --- The problem appears to be unrelated to the referenced patch. Debugging shows that we have a node that has been removed from the cgraph_nodes list. Because the node is not on the cgraph_nodes list, the node->prev->next == node invariant does not hold, and so the code generated by the chain_next/chain_prev GTY annotations segfaults. The node is still reachable from another node's next_needed, which seems like the real bug. Honza agreed to work on the problem on IRC. The easiest way to show the problem is to manually add if (x != NULL && x != (void *)1 && x->previous == NULL && x != cgraph_nodes) abort (); to gt_ggc_mx_cgraph_node. -- What|Removed |Added AssignedTo|rth at gcc dot gnu dot org |jh at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20225
[Bug rtl-optimization/18628] [4.0/4.1 regression] miscompilation of switch statement in loop
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-10 13:46 --- Subject: Re: [PR middle-end/18628] do not fold to label load from tablejump to reg On Wed, Mar 09, 2005 at 07:26:37AM -0300, Alexandre Oliva wrote: > + /* If it's not a REG, the REG_EQUAL note is inappropriate. */ > + if (REG_P (SET_DEST (set))) > + set_unique_reg_note (insn, REG_EQUAL, label); I don't think this is a good idea at all. This is just asking for reload to recreate a reference to the deleted label. r~ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18628
[Bug rtl-optimization/20331] [3.4/4.0/4.1 Regression] Wrong code generation for the argument of the pure function in PIC
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-10 13:57
---
I'll agree that modified_{in,between}_p need to check the address for changes,
since that controls the ultimate value that is accessed.
I do not agree that alias.c needs to check the address for changes. In that
case we're trying to determine if assigning a value to one memory reference
can possibly change the value of another memory reference. Which is false for
*all* read-only memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20331
[Bug debug/20403] dwarf-3: DW_MACINFO_define - wrong lineno fields for predefined macros
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-03-10 14:01 --- This is technically correct. In 4.0 we are still off by a single line, we claim it to be line 1 when it should be 0. We also will output them after the main file starts (this is because of the order of CPP processing). However, this is an incredibly minor bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20403
[Bug c++/20397] g++ rejects valid code with 'is inaccessible' error
--- Additional Comments From matthew dot whitney at gmail dot com 2005-03-10 14:10 --- Thanks for the explanation - I understand what's happening now. Next time I'll take it to comp.lang.c++.moderated before bothering you guys. Anyway sorry to have wasted your time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20397
[Bug c++/18384] [3.3/3.4/4.0/4.1 Regression] ICE on zero-length array with empty initializer...
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-10 14:18 --- Subject: Bug 18384 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-10 14:17:11 Modified files: gcc/cp : ChangeLog gcc/testsuite : ChangeLog gcc/cp : decl.c Added files: gcc/testsuite/g++.dg/init: array19.C Log message: PR c++/18384, c++/18327 * decl.c (reshape_init_array): Use UHWI type for max_index_cst and index. Convert max_index to size_type_node if it isn't host_integerp (, 1). * g++.dg/init/array19.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.8&r2=1.4648.2.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.31&r2=1.5084.2.32 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.2&r2=1.1371.2.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/array19.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18384
[Bug target/19684] avr-gcc 4.0 (and 3.3.4): wrong size in asm comment (peephole)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 14:20 --- Also note peepholes should really be changed to peephole2. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-10 14:20:10 date|| Summary|avr-gcc 4.0 (and 3.3.4):|avr-gcc 4.0 (and 3.3.4): |wrong size in asm comment |wrong size in asm comment ||(peephole) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19684
[Bug c++/18384] [3.3/3.4/4.0/4.1 Regression] ICE on zero-length array with empty initializer...
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-10 14:20 --- Subject: Bug 18384 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-10 14:19:51 Modified files: gcc/cp : ChangeLog gcc/testsuite : ChangeLog gcc/cp : decl.c Added files: gcc/testsuite/g++.dg/init: array19.C Log message: PR c++/18384, c++/18327 * decl.c (reshape_init_array): Use UHWI type for max_index_cst and index. Convert max_index to size_type_node if it isn't host_integerp (, 1). * g++.dg/init/array19.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4658&r2=1.4659 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5136&r2=1.5137 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1376&r2=1.1377 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/array19.C.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18384
[Bug rtl-optimization/20242] Pessimizing effects of defining EXTRA_MEMORY_CONSTRAINT
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-10 14:21:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20242
[Bug c++/18384] [3.3 Regression] ICE on zero-length array with empty initializer...
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-10 14:22 --- Fixed for 3.4/4.0/4.1. -- What|Removed |Added Known to fail|4.0.0 3.4.3 |3.4.3 Known to work|3.3 3.4.0 |3.3 3.4.0 3.4.4 4.0.0 4.1.0 Summary|[3.3/3.4/4.0/4.1 Regression]|[3.3 Regression] ICE on |ICE on zero-length array|zero-length array with empty |with empty initializer... |initializer... Target Milestone|3.4.4 |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18384
[Bug fortran/20361] -fmax-stack-var-size=N not working for equivalence
-- What|Removed |Added OtherBugsDependingO||20405 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20361
[Bug fortran/20405] New: [meta-bug] equivalenced variable problems
There are currently two equivalenced variable problems but I suspect there are more which is why I am creating this meta-bug. -- Summary: [meta-bug] equivalenced variable problems Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: minor Priority: P2 Component: fortran 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 BugsThisDependsOn: 18518,20361 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20405
[Bug fortran/20405] [meta-bug] equivalenced variable problems
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-10 14:34:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20405
[Bug fortran/16511] Test 19990905-0.f fails with gfortran
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 14:38 --- This is an equivalenced problem so linking to 20405 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511
[Bug fortran/16511] Test 19990905-0.f fails with gfortran
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
14:39 ---
The way I came to that conclusion was the following code worked:
c { dg-do compile }
subroutine sub(a)
common /info/ m, n
real a(m,n)
a(1,1) = a(2,2)
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16511
[Bug fortran/18518] equivalenced variables are not saved
-- What|Removed |Added OtherBugsDependingO||20405 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18518
[Bug fortran/20406] New: SIZE() matters?
Dear gfortran developers, This is not a bug, but perhaps in the class of 'unexpected, but notincorrect, behaviour'. This is just for your attention, but not (necessarily) for action as I'm sure there are vastly more important things to deal with. The issue is the return value from size() when the argument is an unassigned pointer - gfortran returns 1. This is illustrated in the attached code snippet. We feel that logically, size() should return zero in these cases (as the Intel and NAG compilers do) or a negative value. However, we accept that any arbitrary value could be returned - as the result is probably undefined according the standards. Not that it should be relied upon, or in a good program, even allowed to occur! The reason for not doing an allocate() and then doing the test with size() and not associated() before deallocation has some history and a complex logic that I won't bore you with here. Suffice to say we are now doing the test properly... All the best, Dave On RH9 Linux: [EMAIL PROTECTED]> gfc --version GNU Fortran 95 (GCC 4.0.0 20050224 (experimental)) ... [EMAIL PROTECTED]> cat ~/packages/bugs/gfc_pointer_problem2.f90 [EMAIL PROTECTED]> gfc -static -o point gfc_pointer_problem2.f90 [EMAIL PROTECTED]> point !!! x associated? F !!! size of x? 1 !!!Fortran runtime error: Internal: Attempt to DEALLOCATE unallocated memory. !!! program point integer, pointer :: x(:) => null() print *, 'x associated?', associated(x) print *, 'size of x? ', size(x) !!! gfc says 1, ifc=nag=0 if(size(x)>0)deallocate(x) !!! wrong! !!! if (associated(x)) deallocate(x)!!! correct end program point -- Summary: SIZE() matters? Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave dot offiler at metoffice dot gov dot uk CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20406
[Bug libfortran/20406] SIZE() matters?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 15:00 --- This is a library problem. -- What|Removed |Added Severity|enhancement |minor Component|fortran |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20406
[Bug target/20375] [4.0/4.1 Regression] C++ ICE in assign_parm_find_entry_rtl
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-10 15:04 --- Subject: Bug 20375 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-10 15:04:39 Modified files: gcc: ChangeLog function.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/other: stdarg3.C Log message: PR c++/20375 * function.c (struct assign_parm_data_one): Remove last_named field. (assign_parm_find_data_types): Don't determine last_named. Reorder named_parm determination. (assign_parms): Only setup varargs on the last non-varadic parameter. testsuite: PR c++/20375 * g++.dg/other/stdarg3.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7768&r2=2.7769 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcc&r1=1.605&r2=1.606 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5137&r2=1.5138 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/stdarg3.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20375
[Bug target/20375] [4.0/4.1 Regression] C++ ICE in assign_parm_find_entry_rtl
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-10 15:11 --- Subject: Bug 20375 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-10 15:11:25 Modified files: gcc: ChangeLog function.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/other: stdarg3.C Log message: PR c++/20375 * function.c (struct assign_parm_data_one): Remove last_named field. (assign_parm_find_data_types): Don't determine last_named. Reorder named_parm determination. (assign_parms): Only setup varargs on the last non-varadic parameter. testsuite: PR c++/20375 * g++.dg/other/stdarg3.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.36&r2=2.7592.2.37 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.604&r2=1.604.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.32&r2=1.5084.2.33 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/stdarg3.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20375
[Bug c++/20381] [4.0/4.1 Regression] ICE in build_ptrmemfunc, at cp/typeck.c:5702
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-10 15:11 --- Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01028.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20381
[Bug c++/20407] New: Rejects valid C99 for the C++ front-end
The following code is rejects (even though it is valid C99 and Mark said we
should have the C++ front-
end accept it also):
typedef struct {
unsigned char dir;
int data[];
} AiDefaultRailBlock;
static const AiDefaultRailBlock _raildata_ai_0 = { 1, { 0, 4 } };
--
Summary: Rejects valid C99 for the C++ front-end
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: minor
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20407
[Bug c++/18327] [3.3 Regression] ICE while compiling valid c code with g++
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 15:12 --- The ICE has been fixed on the mainline, 3.4 and 4.0 branches but we still have a rejects valid, which I filed as PR 20407. -- What|Removed |Added OtherBugsDependingO||20407 nThis|| Summary|[3.3/3.4/4.0/4.1 Regression]|[3.3 Regression] ICE while |ICE while compiling valid c |compiling valid c code with |code with g++ |g++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18327
[Bug c++/20407] Rejects valid C99 for the C++ front-end
-- What|Removed |Added BugsThisDependsOn||18327 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20407
[Bug middle-end/20225] [4.0/4.1 regression] ICE during GC
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-10 15:15 --- Err, sorry, that "how to reproduce" snippet depended on some other changes in my tree. You'll have to check node->previous && node->previous->next != node. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20225
[Bug target/20375] [4.0/4.1 Regression] C++ ICE in assign_parm_find_entry_rtl
--- Additional Comments From nathan at gcc dot gnu dot org 2005-03-10 15:23 --- 2005-03-10 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/20375 * function.c (struct assign_parm_data_one): Remove last_named field. (assign_parm_find_data_types): Don't determine last_named. Reorder named_parm determination. (assign_parms): Only setup varargs on the last non-varadic parameter. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20375
[Bug target/20375] [4.0/4.1 Regression] C++ ICE in assign_parm_find_entry_rtl
-- What|Removed |Added Target Milestone|4.1.0 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20375
[Bug middle-end/20408] New: Unnessasary code generated for empty structs
Given an empty struct (ie struct X { };), even at high optimisation levels g++
will insist on always allocating and zeroing some memory for empty structs.
This actually effects C++ code, including libstdc++-v3, as empty structs are
often used as a means of passing around functions.
EXAMPLE
--
struct X {};
void foo(X);
void call_foo()
{ foo(X()); }
--
generates (from -O3, t70.final_cleanup is:)
-
;; Function void call_foo() (_Z8call_foov)
void call_foo() ()
{
struct X D.1597;
:
D.1597 = 0;
foo (D.1597) [tail call];
return;
}
-
--
Summary: Unnessasary code generated for empty structs
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
[Bug c++/20408] Unnessasary code generated for empty structs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
15:56 ---
Note this has no effect on the generated code.
But anyways:
struct X D.1574;
struct X D.1590;
D.1574 = {};
D.1590 = 0;
That is not right 0 is an INTEREGER_CST which cannot be an aggregate, that is
just wrong.
If we had more type checking we would be an ICE.
--
What|Removed |Added
Severity|minor |normal
Status|UNCONFIRMED |NEW
Component|middle-end |c++
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-03-10 15:56:21
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
[Bug c++/20408] Unnecessary code generated for empty structs
-- What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
[Bug c++/20407] Rejects valid C99 for the C++ front-end
--- Additional Comments From joseph at codesourcery dot com 2005-03-10
15:59 ---
Subject: Re: New: Rejects valid C99 for the C++ front-end
On Thu, 10 Mar 2005, pinskia at gcc dot gnu dot org wrote:
> The following code is rejects (even though it is valid C99 and Mark said we
> should have the C++ front-
> end accept it also):
> typedef struct {
> unsigned char dir;
> int data[];
> } AiDefaultRailBlock;
> static const AiDefaultRailBlock _raildata_ai_0 = { 1, { 0, 4 } };
Initialization of flexible array members is not valid C99; it is a GNU
extension.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20407
[Bug c++/20408] Unnecessary code generated for empty structs
--- Additional Comments From chris at bubblescope dot net 2005-03-10 16:00 --- ignore my random changing of severity.. -- What|Removed |Added Severity|minor |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
[Bug c++/20408] Unnecessary code generated for empty structs
--- Additional Comments From chris at bubblescope dot net 2005-03-10 16:05 --- When you say "has no effect in final code", are you talking about the problem you noticed, or the problem as a whole? I find for each extra X I add to the type of foo I get a line much like: movb %al, 28(%esp) appearing in the assembler output, which I assume isn't necessary.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
[Bug c++/20408] Unnecessary code generated for empty structs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 16:10 --- Werid on PPC, we get the most optimal code of __Z8call_foov: LFB2: b __Z3foo1X -- What|Removed |Added Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
[Bug target/20409] New: ICE in simplify_subreg with -fprofile-generate
/* { dg-do compile } */
/* { dg-options "-O2 -fprofile-generate" } */
struct S
{
int a;
void **b;
};
void
foo (struct S *x, int y)
{
if (!x)
return;
if (y >= x->a)
return;
x->a--;
for (; y < x->a; y++)
x->b[y] = x->b[y + 1];
x->b[x->a] = (void *) 0;
}
ICEs on IA-64 during combine, but the bug is earlier.
CSE2 creates:
(insn 42 41 87 3 (set (reg/v:SI 344 [ y.8 ])
(reg:DI 378)) 4 {*movsi_internal} (nil)
(nil))
which is invalid because the modes don't match.
Before CSE2 there is:
(insn 100 99 101 0 (set (reg:DI 378)
(reg:DI 113 in1)) -1 (nil)
(nil))
...
(insn 103 102 104 0 (set (reg:DI 113 in1)
(reg:DI 378)) -1 (nil)
(nil))
...
(insn 12 11 13 0 (set (reg/v:SI 350 [ y ])
(reg:SI 113 in1 [ y ])) 4 {*movsi_internal} (nil)
(nil))
...
(insn 42 41 87 3 (set (reg/v:SI 344 [ y.8 ])
(reg/v:SI 350 [ y ])) 4 {*movsi_internal} (nil)
(nil))
where insns 100 and 103 and code around it are created by .bp pass.
--
Summary: ICE in simplify_subreg with -fprofile-generate
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: critical
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20409
[Bug c++/20408] Unnecessary code generated for empty structs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 16:21 --- (In reply to comment #5) > Andrew, is Daniel Berlin struct aliasing work likely to help, here? No, fixing the front-end so it no longer produces a = 0 will most likely fix this as that is just wrong. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
[Bug target/20409] ICE in simplify_subreg with -fprofile-generate
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 16:24 --- This is not a target bug but rather a bug in CSE. This is a dup of bug 20249. *** This bug has been marked as a duplicate of 20249 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20409
[Bug rtl-optimization/20249] [4.0/4.1 Regression] ICE with -fprofile-arcs on ppc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 16:25 --- *** Bug 20409 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20249
[Bug c++/20408] Unnecessary code generated for empty structs
--- Additional Comments From pcarlini at suse dot de 2005-03-10 16:19 --- Andrew, is Daniel Berlin struct aliasing work likely to help, here? -- What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
internal compiler error in 3.4.3-20050110
Hello, I have problem using gcc 3.4.3. preprocessed file is attached. Gcc 3.3.x works right, several 3.4.x's checked so far crashed. Marcin Mogielnicki, ICM, Poland # gcc -c -Wall -std=gnu99 -mmmx -msse -D_GNU_SOURCE -ffast-math overfit.c -fPIC -DPIC -o overfit.o overfit.c: In function `overfit_setstart': overfit.c:337: internal compiler error: in simplify_gen_subreg, at simplify-rtx.c:3521 Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/> for instructions. Preprocessed source stored into /tmp/ccKLbdAG.out file, please attach this to your bugreport. # gcc -v Reading specs from /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3-20050110/specs Configured with: /var/tmp/portage/gcc-3.4.3.20050110/work/gcc-3.4.3/configure --enable-version-specific-runtime-libs --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.3-20050110 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3-20050110/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.3-20050110 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.3-20050110/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.3-20050110/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3-20050110/include/g++-v3 --host=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --enable-multilib --disable-libgcj --enable-languages=c,c++,f77 --enable-shared --enable-threads=posix Thread model: posix gcc version 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7.7) # uname -a Linux n97 2.6.11-rc5-current #2 SMP Mon Feb 28 14:28:10 CET 2005 x86_64 AMD Opteron(tm) Processor 246 AuthenticAMD GNU/Linux The exact line which triggers bug is: /usr/libexec/gcc/x86_64-pc-linux-gnu/3.4.3-20050110/cc1 -quiet -D_GNU_SOURCE -DPIC overfit.i -quiet -dumpbase overfit.c -mmmx -msse -mtune=k8 -auxbase-strip overfit.o -Wall -std=gnu99 -ffast-math -fPIC -o - -frandom-seed=0 overfit.i.gz Description: Binary data
[Bug c++/20408] Unnecessary code generated for empty structs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
17:06 ---
>From call.c:
/* Don't pass empty class objects by value. This is useful
for tags in STL, which are used to control overload resolution.
We don't need to handle other cases of copying empty classes. */
if (! decl || ! DECL_BUILT_IN (decl))
for (tmp = parms; tmp; tmp = TREE_CHAIN (tmp))
if (is_empty_class (TREE_TYPE (TREE_VALUE (tmp)))
&& ! TREE_ADDRESSABLE (TREE_TYPE (TREE_VALUE (tmp
{
tree t = build0 (EMPTY_CLASS_EXPR, TREE_TYPE (TREE_VALUE (tmp)));
TREE_VALUE (tmp) = build2 (COMPOUND_EXPR, TREE_TYPE (t),
TREE_VALUE (tmp), t);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
[Bug c++/20408] Unnecessary code generated for empty structs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 17:07 --- >From cp-gimplifier.c: case EMPTY_CLASS_EXPR: /* We create an INTEGER_CST with RECORD_TYPE and value zero. */ *expr_p = build_int_cst (TREE_TYPE (*expr_p), 0); This is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
[Bug c++/20408] Unnecessary code generated for empty structs
--- Additional Comments From pcarlini at suse dot de 2005-03-10 17:13 --- Eh, I was looking at the very same code... Can't we deal with EMPTY_CLASS_EXPR similarly to USING_STMT? ;) ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
[Bug c++/20408] Unnecessary code generated for empty structs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 17:15 --- (In reply to comment #9) > Eh, I was looking at the very same code... Can't we deal with EMPTY_CLASS_EXPR > similarly to USING_STMT? ;) ;) I think we should produce an empty CONSTRUCTOR (which I am testing right now). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
[Bug middle-end/20408] Unnecessary code generated for empty structs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
17:30 ---
(In reply to comment #10)
> I think we should produce an empty CONSTRUCTOR (which I am testing right now).
That did not fix it, we still get code generated for the "empty" struct:
;; D.1594 = {}
(nil)
;; foo (D.1594) [tail call]
(insn 10 8 11 (set (mem:QI (reg/f:SI 56 virtual-outgoing-args) [0 S1 A32])
(reg:QI 58 [ D.1594 ])) -1 (nil)
(nil))
(call_insn 11 10 0 (call (mem:QI (symbol_ref:SI ("_Z3foo1X") [flags 0x41]
) [0 S1 A8])
(const_int 4 [0x4])) -1 (nil)
(nil)
(nil))
But on PPC we get:
;; D.1588 = {}
(nil)
;; foo (D.1588) [tail call]
(insn 10 8 11 0 (set (reg:QI 3 r3)
(reg:QI 118 [ D.1588 ])) -1 (nil)
(nil))
(call_insn/j 11 10 12 0 (parallel [
(call (mem:SI (symbol_ref:SI ("_Z3foo1X") [flags 0x41]
) [0 S4
A8])
(const_int 32 [0x20]))
(use (const_int 0 [0x0]))
(use (reg:SI 119))
(return)
]) -1 (nil)
(nil)
(expr_list:REG_DEP_TRUE (use (reg:QI 3 r3))
(nil)))
See the difference is that we pass on ppc via a register but on x86 we pass via
the stack. I don't know a
way to fix this with a front-end change.
--
What|Removed |Added
Component|c++ |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
[Bug middle-end/20408] Unnecessary code generated for empty structs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 17:35 --- The change to cp-gimplifier.c should still happen as it makes not create a INTEGER_CST for an aggregate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
[Bug c/20410] New: Add support for UTF-16 string syntax to C and C++
This is a request for enhancement. Please add platform independent UTF-16 string syntax (platform independent means not using wchar_t). The variability of the wchar_t type makes it unsuitable for UTF-16 strings. This request is to implement ISO/IEC JTC1 SC22 WG14's technical report that is titled, "Extensions for the programming language C to support new character data types". A copy of the technical report can be found here: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1040.pdf There are already several compilers that support the u"" string syntax. IBM Visual Age 7 and HP-UX aCC A.03.37 are two compilers that support the u"" syntax. Several other compilers already support UTF-16 strings through other types of syntax (using U"" or L""). gcc is one of the few compilers that has no UTF-16 syntax in the compiler. Our project doesn't need any of the functions or the UTF-32 type that are mentioned in the technical report. The ability to declare a UTF-16 string as u"This is my string with a \u03BC" would be very helpful to us. -- Summary: Add support for UTF-16 string syntax to C and C++ Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: grhoten at jtcsv dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20410
[Bug c/20410] Add support for UTF-16 string syntax to C and C++
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 18:12 --- Confirmed, but this will most likely not going to happen until this is approved or is decided that is about to be approved. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-10 18:12:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20410
[Bug c/20410] Add support for UTF-16 string syntax to C and C++
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 18:12 --- Suspending until then. -- What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20410
[Bug c++/19817] C++ front-end produces a cast instead of just &a.b (when call the deconstructor)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 18:17 --- The bug is in convert_to_base_statically. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19817
[Bug rtl-optimization/20331] [3.4/4.0/4.1 Regression] Wrong code generation for the argument of the pure function in PIC
--- Additional Comments From joern dot rennecke at st dot com 2005-03-10
18:18 ---
Subject: Re: [3.4/4.0/4.1 Regression] Wrong code generation for the argument
of the pure function in PIC
rth at gcc dot gnu dot org wrote:
>--- Additional Comments From rth at gcc dot gnu dot org 2005-03-10 13:57
>---
>I'll agree that modified_{in,between}_p need to check the address for changes,
>since that controls the ultimate value that is accessed.
>
>I do not agree that alias.c needs to check the address for changes. In that
>case we're trying to determine if assigning a value to one memory reference
>can possibly change the value of another memory reference. Which is false for
>*all* read-only memory.
>
>
>
After looking a bit more at true_dependence and friends, I think you are
right; the callers have
checked or will be checking the address. And apart from the dependency
functions in alias.c,
I could find only modified_{in,between}_p using MEM_READONLY_P to
indicate that the
entire MEM doesn't change.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20331
[Bug java/20312] No warning on bad method
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-10 18:40 --- Subject: Bug 20312 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-10 18:40:28 Modified files: gcc/java : ChangeLog parse.y Log message: PR java/20312 * parse.y (checks_throws_clauses): Check exceptions list even when the base class does not come from a source file being compiled. (java_complete_lhs): Remove unused variable 'wfl'. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1570&r2=1.1571 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/parse.y.diff?cvsroot=gcc&r1=1.529&r2=1.530 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20312
[Bug middle-end/20411] New: Templated functions no inlined at -O2
I believe this is a known problem, but I couldn't find it anywhere.
The inliner at -O2 will attempt to inline any small functions. It will not
however try to inline functions will external linkage, which includes all
templated functions.
As much C++ code (including libstdc++) contains many small templated functions,
this means it is necessary to mark all these functions as inline to ensure they
are even considered at -O2.
Example: given:
void foo() {}
void foo2() {foo();}
int main() {foo2();}
then main() is optimised away to an empty function at -O2. However:
template
void foo() {}
template
void foo2() {foo();}
int main() {foo2();}
leaves the calls to foo2 and foo in at -O2.
Is there a good reason to not pull inlining of small functions (which in C++
typically consist of simply calling a new function with almost identical
parameters) into -O2, even when they have external linkage? (or make an
exception for templated functions?)
--
Summary: Templated functions no inlined at -O2
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20411
[Bug regression/20412] New: ICE when -O1, regression from gcc-3.4.3
/*
gcc-4.0 sparc-SunOS bug
gcc-4.0 -O0 -c foo.c // ok
gcc-4.0 -O1 -c foo.c // ICE
% gcc-4.0 -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: /home/kate/gcc-4.0-20050305/src/gcc-4.0-20050305/configure
--enable-languages=c --prefix=/home/kate/gcc-4.0-20050305/sparc-SunOS
Thread model: posix
gcc version 4.0.0 20050305 (prerelease)
%
*/
#define FALSE 0
int
foo()
{
int a,b,g;
int i,len;
int stop;
len = 10;
stop = FALSE;
for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=20412
[Bug libgcj/20392] invalid install/relink of llibgcj{,0_convenience} during `make install`
--- Additional Comments From pluto at pld-linux dot org 2005-03-10 19:01 --- [~/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/i686-pld-linux/libjava/.libs] drwxr-xr-x 2 pluto users 4096 2005-03-10 19:51 . drwxr-xr-x 15 pluto users 4096 2005-03-10 19:51 .. -rw--- 1 pluto users11600 2005-03-10 19:42 boehm.o -rw--- 1 pluto users35316 2005-03-10 19:37 defineclass.o -rw-r--r-- 1 pluto users 4816 2005-03-10 00:30 exception.o -rwx-- 1 pluto users33329 2005-03-10 19:51 gcj-dbtool -rwx-- 1 pluto users 6409 2005-03-10 19:51 gij -rw-r--r-- 1 pluto users 6612 2005-03-10 01:51 gij.o -rwx-- 1 pluto users 6764 2005-03-10 19:51 grmic -rwx-- 1 pluto users 6793 2005-03-10 19:51 grmiregistry -rw--- 1 pluto users45404 2005-03-10 19:38 interpret.o -rw--- 1 pluto users 119072 2005-03-10 19:37 jni.o -rwx-- 1 pluto users 6765 2005-03-10 19:51 jv-convert -rw--- 1 pluto users 32257574 2005-03-10 19:49 libgcj0_convenience.a lrwxrwxrwx 1 pluto users 25 2005-03-10 19:49 libgcj0_convenience.la -> ../libgcj0_convenience.la -rw--- 1 pluto users 1319 2005-03-10 19:49 libgcj0_convenience.lai lrwxrwxrwx 1 pluto users 28 2005-03-10 19:47 libgcj0_convenience.so -> libgcj0_convenience.so.0.0.0 lrwxrwxrwx 1 pluto users 28 2005-03-10 19:47 libgcj0_convenience.so.0 -> libgcj0_convenience.so.0.0.0 -rwx-- 1 pluto users 19935083 2005-03-10 19:47 libgcj0_convenience.so.0.0.0 -rw--- 1 pluto users 1661364 2005-03-10 19:49 libgcj.a lrwxrwxrwx 1 pluto users 12 2005-03-10 19:49 libgcj.la -> ../libgcj.la -rw--- 1 pluto users 1299 2005-03-10 19:49 libgcj.lai lrwxrwxrwx 1 pluto users 15 2005-03-10 19:49 libgcj.so -> libgcj.so.6.0.0 lrwxrwxrwx 1 pluto users 15 2005-03-10 19:49 libgcj.so.6 -> libgcj.so.6.0.0 -rwx-- 1 pluto users 928202 2005-03-10 19:49 libgcj.so.6.0.0 -rw--- 1 pluto users 5170 2005-03-10 19:50 libgij.a lrwxrwxrwx 1 pluto users 12 2005-03-10 19:50 libgij.la -> ../libgij.la -rw--- 1 pluto users 1444 2005-03-10 19:50 libgij.lai lrwxrwxrwx 1 pluto users 15 2005-03-10 19:50 libgij.so -> libgij.so.6.0.0 lrwxrwxrwx 1 pluto users 15 2005-03-10 19:50 libgij.so.6 -> libgij.so.6.0.0 -rwx-- 1 pluto users10298 2005-03-10 19:50 libgij.so.6.0.0 -rw--- 1 pluto users29780 2005-03-10 19:37 link.o -rw--- 1 pluto users 4380 2005-03-10 19:42 posix.o -rw--- 1 pluto users 7572 2005-03-10 19:42 posix-threads.o -rw--- 1 pluto users32348 2005-03-10 19:36 prims.o -rw--- 1 pluto users 106304 2005-03-10 19:38 verify.o Hmm, build is fine but when relinking fails libgcj.so.6.0.0 dissappears (libtool script removes it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20392
[Bug libgcj/20392] invalid install/relink of llibgcj{,0_convenience} during `make install`
--- Additional Comments From pluto at pld-linux dot org 2005-03-10 19:11 --- I've recheckd the install log and found the reason of relinking error. /home/users/pluto/multimedia/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/gcc/xgcc -shared-libgcc -B/home/users/pluto/multimedia/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/gcc/ -nostdinc++ -L/home/users/pluto/multimedia/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/i686-pld-linux/libstdc++-v3/src -L/home/users/pluto/multimedia/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/i686-pld-linux/libstdc++-v3/src/.libs -B/usr/i686-pld-linux/bin/ -B/usr/i686-pld-linux/lib/ -isystem /usr/i686-pld-linux/include -isystem /usr/i686-pld-linux/sys-include -shared -nostdlib /usr/lib/gcc/i686-pld-linux/4.0.0/../../../crti.o /home/users/pluto/multimedia/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/gcc/crtbeginS.o gnu/regexp/.libs/MessagesBundle.properties.o gnu/regexp/.libs/MessagesBundle_fr.properties.o org/ietf/jgss/.libs/MessagesBundle.properties.o -Wl,--whole-archive external/sax/.libs/libsax_convenience.a external/w3c_dom/.libs/libw3c_convenience.a ../libffi/.libs/libffi_convenience.a ../boehm-gc/.libs/libgcjgc_convenience.a ./libltdl/.libs/libltdlc.a -Wl,--no-whole-archive -L/tmp/gcc-4.0.0-root-pluto/usr/lib -L/home/users/pluto/multimedia/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/i686-pld-linux/libstdc++-v3/src -L/home/users/pluto/multimedia/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/i686-pld-linux/libstdc++-v3/src/.libs -L/home/users/pluto/multimedia/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/i686-pld-linux/libjava external/sax/.libs/libsax_convenience.a external/w3c_dom/.libs/libw3c_convenience.a -L/usr/lib -lgcj0_convenience -L/home/users/pluto/multimedia/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/gcc -L/usr/lib/gcc/i686-pld-linux/4.0.0 -L/usr/lib/gcc/i686-pld-linux/4.0.0/../../.. ../libffi/.libs/libffi_convenience.a ../boehm-gc/.libs/libgcjgc_convenience.a -lpthread ./libltdl/.libs/libltdlc.a -ldl -lz -lgcc_s -lc -lgcc_s /home/users/pluto/multimedia/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/gcc/crtendS.o /usr/lib/gcc/i686-pld-linux/4.0.0/../../../crtn.o -Wl,-soname -Wl,libgcj.so.6 -o .libs/libgcj.so.6.0.0 /usr/bin/ld: cannot find -lgcj0_convenience collect2: ld returned 1 exit status Adding below path helpd. -L/home/users/pluto/multimedia/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/i686-pld-linux/libjava/.libs -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20392
[Bug middle-end/20411] Templated functions are not found pure/const
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 19:21 --- Note there are two problems here, foo2/foo in the orginal example are found to pure/const function so they are optimizated away which is different than inlining. This all fixed on the tree profiling branch where we actually find the templates functions are pure/const also. Note at -Os we do turn on -finline-functions and inline small functions. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-03-10 19:21:48 date|| Summary|Templated functions no |Templated functions are not |inlined at -O2 |found pure/const http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20411
[Bug c++/20381] [4.0/4.1 Regression] ICE in build_ptrmemfunc, at cp/typeck.c:5702
--- Additional Comments From micis at gmx dot de 2005-03-10 19:25 --- I did a bootstrap and run the checks on x86_64-linux. No new regressions. Then I compiled my application including QT 3.3.4, ACE 5.4.2, GSL 1.5 and all worked well. Many thanks for the quick fix. Michael Cieslinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20381
[Bug regression/20412] [4.0/4.1 Regression] RTL checking failure in the combiner
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-10 19:40 --- Confirmed: pr20412.c: In function 'foo': pr20412.c:20: internal compiler error: RTL check: expected elt 0 type 'e' or 'u', have 'i' (rtx reg) in simplify_set, at combine.c:5145 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-10 19:40:51 date|| Summary|ICE when -O1, regression|[4.0/4.1 Regression] RTL |from gcc-3.4.3 |checking failure in the ||combiner Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20412
[Bug rtl-optimization/20412] [4.0/4.1 Regression] RTL checking failure in the combiner
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 19:41 --- Without RTL checking we get this backtrace: #0 0x0066027c in simplify_comparison (code=REG, pop0=0xbfffef8c, pop1=0xbfffef90) at ../../gcc/ combine.c:9584 #1 0x00650ad4 in simplify_set (x=0x4157ab04) at ../../gcc/combine.c:5169 #2 0x0064e8c4 in combine_simplify_rtx (x=0x4157ab04, op0_mode=VOIDmode, in_dest=0) at ../../ gcc/combine.c:4640 #3 0x0064b4cc in subst (x=0x4157ab04, from=0x41575800, to=0x4157aabc, in_dest=0, unique_copy=0) at ../../gcc/combine.c:3682 #4 0x006459cc in try_combine (i3=0x41573a78, i2=0x41573a50, i1=0x41573a00, new_direct_jump_p=0xb454) at ../../gcc/combine.c:2055 #5 0x00641f84 in combine_instructions (f=0x41506f60, nregs=133) at ../../gcc/combine.c:774 -- What|Removed |Added Component|regression |rtl-optimization Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20412
[Bug middle-end/19985] executables created with -fprofile-arcs -ftest-coverage segfault in gcov_exit ()
--- Additional Comments From janis at gcc dot gnu dot org 2005-03-10 19:42 --- Created an attachment (id=8373) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8373&action=view) smaller C test case The test case provided by the submitter runs successfully if the executable is built without -Wl,-E, as does the smaller C test case. I understand that the original program needs to use that option, so I'll continue looking into this to find a fix and perhaps a workaround. The new test case fails with a plain "make" invocation for mainline, 4.0-branch, and 3.4-branch, and passes for all of those with "make EXP=". -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janis at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19985
[Bug rtl-optimization/20412] [4.0/4.1 Regression] RTL checking failure in the combiner
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 19:48 --- Hmm, we are simplifing the following RTL: (compare:CC (ne:SI (reg:SI 131) (const_int 0 [0x0])) (const_int 0 [0x0])) To: (reg:SI 131) Which is wrong (but I should note that simplify_set for compare does not handle reg RTL). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20412
[Bug libgcj/20392] invalid install/relink of llibgcj{,0_convenience} during `make install`
--- Additional Comments From pluto at pld-linux dot org 2005-03-10 19:53 --- Created an attachment (id=8374) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8374&action=view) test patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20392
[Bug c++/20401] error message is misleading
--- Additional Comments From bangerth at dealii dot org 2005-03-10 19:55 --- This is a duplicate of a good number of other PRs. I don't have the time right now to find them, though... W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20401
[Bug c++/20401] error message is misleading
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 19:56 --- I could sware I closed this as a dup of bug 100 before. *** This bug has been marked as a duplicate of 100 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20401
[Bug c++/100] confusing name lookup diagnostic
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 19:56 --- *** Bug 20401 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||papadopo at shfj dot cea dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=100
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- What|Removed |Added BugsThisDependsOn||20413 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug rtl-optimization/20413] New: VOIDmode LABEL_REFs are generated
Various parts of the compiler generate LABEL_REFS with VOIDmode instead of Pmode. This can cause some optimizations to be missed because two pieces of code might be identical, except for the mode of their LABEL_REFS - then they still compare as non-equal, e.g. for if-conversion or cross-jumping. For targets that have varying Pmode settings and therefore use jump patterns that don't specify the mode so that they can match e.g. either SImode of DImode, the situation is more dire: when reload has to load the label into a register, it needs the mode of the label_ref to determine the load of the reload. VOIDmode in this place leads to an ICE, which is likely to prevent building the gcc support libraries. -- Summary: VOIDmode LABEL_REFs are generated Product: gcc Version: 3.2 Status: UNCONFIRMED Keywords: ice-on-valid-code, missed-optimization, build Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org OtherBugsDependingO 17652 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20413
[Bug rtl-optimization/20413] VOIDmode LABEL_REFs are generated
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-10 19:59 --- Created an attachment (id=8375) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8375&action=view) patch against 3.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20413
[Bug rtl-optimization/20412] [4.0/4.1 Regression] RTL checking failure in the combiner
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
20:09 ---
Found the typo.
The following patch fixes the ICE and corrects the mode problem.
I will apply this as ovbious as this was broken when
simplify_relational_operation_1 was moved out of
simplify_relational_operation.
Index: simplify-rtx.c
===
RCS file: /cvs/gcc/gcc/gcc/simplify-rtx.c,v
retrieving revision 1.232
diff -u -p -r1.232 simplify-rtx.c
--- simplify-rtx.c 5 Mar 2005 17:25:32 - 1.232
+++ simplify-rtx.c 10 Mar 2005 20:07:34 -
@@ -2882,7 +2882,7 @@ simplify_relational_operation_1 (enum rt
/* If op0 is a comparison, extract the comparison arguments form it.
*/
if (code == NE)
{
- if (GET_MODE (op0) == cmp_mode)
+ if (GET_MODE (op0) == mode)
return simplify_rtx (op0);
else
return simplify_gen_relational (GET_CODE (op0), mode, VOIDmode,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20412
[Bug rtl-optimization/18628] [4.0/4.1 regression] miscompilation of switch statement in loop
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-10
20:38 ---
Subject: Re: [PR middle-end/18628] do not fold to label load from tablejump to
reg
On Mar 10, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 09, 2005 at 07:26:37AM -0300, Alexandre Oliva wrote:
>> +/* If it's not a REG, the REG_EQUAL note is inappropriate. */
>> +if (REG_P (SET_DEST (set)))
>> + set_unique_reg_note (insn, REG_EQUAL, label);
> I don't think this is a good idea at all. This is just
> asking for reload to recreate a reference to the deleted label.
Here's a patch with that bit removed, along with the change in
cse_init that it required. Ok?
Index: gcc/ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
PR middle-end/18628
* cse.c (fold_rtx_mem): Don't fold a load from a jumptable into a
register.
Index: gcc/cse.c
===
RCS file: /cvs/gcc/gcc/gcc/cse.c,v
retrieving revision 1.349
diff -u -p -r1.349 cse.c
--- gcc/cse.c 8 Mar 2005 13:56:56 - 1.349
+++ gcc/cse.c 10 Mar 2005 20:36:36 -
@@ -3515,8 +3515,30 @@ fold_rtx_mem (rtx x, rtx insn)
if (offset >= 0
&& (offset / GET_MODE_SIZE (GET_MODE (table))
< XVECLEN (table, 0)))
- return XVECEXP (table, 0,
- offset / GET_MODE_SIZE (GET_MODE (table)));
+ {
+ rtx label = XVECEXP
+ (table, 0, offset / GET_MODE_SIZE (GET_MODE (table)));
+ rtx set;
+
+ /* If we have an insn that loads the label from the
+ jumptable into a reg, we don't want to set the reg
+ to the label, because this may cause a reference to
+ the label to remain after the label is removed in
+ some very obscure cases (PR middle-end/18628). */
+ if (!insn)
+ return label;
+
+ set = single_set (insn);
+
+ if (! set || SET_SRC (set) != x)
+ return x;
+
+ /* If it's a jump, it's safe to reference the label. */
+ if (SET_DEST (set) == pc_rtx)
+ return label;
+
+ return x;
+ }
}
if (table_insn && JUMP_P (table_insn)
&& GET_CODE (PATTERN (table_insn)) == ADDR_DIFF_VEC)
Index: gcc/testsuite/ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
* gcc.dg/pr18628.c: New.
Index: gcc/testsuite/gcc.dg/pr18628.c
===
RCS file: gcc/testsuite/gcc.dg/pr18628.c
diff -N gcc/testsuite/gcc.dg/pr18628.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ gcc/testsuite/gcc.dg/pr18628.c 10 Mar 2005 20:36:52 -
@@ -0,0 +1,31 @@
+/* { dg-do link } */
+/* { dg-options "-O2" } */
+
+/* PR middle-end/18628 exposed a problem in which cse folded a load
+ from a jump table into the label that was the target of the branch.
+ Unfortunately, the indirect jump was moved to a different basic
+ block, and the LABEL_REF copied to the register wasn't enough to
+ keep the cfg from optimizing the otherwise-unused label away. So
+ we ended up with a dangling reference to the label. */
+
+int i;
+
+int main()
+{
+ for (;;)
+ {
+switch (i)
+{
+ case 0:
+ case 1:
+return 1;
+
+ case 2:
+ case 3:
+return 0;
+
+ case 5:
+--i;
+}
+ }
+}
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18628
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From joel at gcc dot gnu dot org 2005-03-10 20:50 --- Any chance of this getting committed to the 3.4, 4.0 and 4.1 branches so it can be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
[Bug c++/20414] New: C-style cast fails to do proper conversion (explicit type conversion)
It seems that g++ is not compliant with the standard for old-style C casts -
potentially causing programs to crash.
Below is a code sample followed by an detailing of what happens in practice, and
what I think should happen. Cast#5 is the problematic cast.
CODE STARTS HERE =
#include
struct B
{
B (const char *s):str (s)
{
}
const char *str;
};
struct H
{
H (const char *s)
{
strcpy (str, s);
}
operator const B ()
{
return B (str);
}
char str[1024];
};
void
f (const B & b)
{
std::cout << b.str << std::endl;
}
int
main (int argc, char *argv[])
{
H h ("hi4243");
// cast #1: initialization by conversion for reference binding OK
const B &b = h;
// cast #2: direct-initialization
const B b2(h);
// cast #3: explicit static_cast OK
f (static_cast(h));
// cast #4: C-style cast, works as expected OK
f ((const B)h);
// cast #5: C-style cast, should cause an implicit conversion sequence,
// but it does not ERROR!! program will crash
f ((const B &)h);
return 0;
}
CODE ENDS HERE =
Here is what g++ does for each cast:
#1 - call the conversion operator in H to turn 'h' to type B and then proceed
using a standard conversion sequence. This is compliant with "Section 13.3.1.6
Initialization by conversion function for direct reference binding" of the
standard.
#2 - essentially does the same as #1, but is there to show the validity of the
static_cast in cast #3 based on "Section 5.2.9 Static cast clause 2" of the
standard. The process itself is described in "Section 8.5 clauses 12 and 14" of
the standard.
#3 - performs an explicit static_cast to a reference type. Cast #2 shows that
this is well-formed.
#4 - performs a cast using the user-defined conversion operator as expected.
#5 - performs the equivalent of a reinterpret_cast. This causes the program to
crash.
The standard is clear in saying that when an old-style C-cast("explicit type
conversion"/"cast notation") is used, the compiler should attempt the conversion
-exactly- in this order: const_cast, static_cast, static_cast followed by
const_cast, reinterpret_cast, and reinterpret_cast followed by a const_cast. It
goes on to say that if more than one cast is possible, the -first- one in this
list should be used.
The code sample above shows that a static_cast works properly(#3), but an
explicit cast(#5) fails to detect the possibility of using a static_cast;
moreover, cast #4 seems to indicate that the problem is g++'s failure to do a
standard conversion sequence before looking up the user-defined conversion
operator in H.
I might be misreading or misunderstanding the standard, so if that is the case,
please let me know.
Thanks,
Simon
--
Summary: C-style cast fails to do proper conversion (explicit
type conversion)
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simonc235 at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20414
[Bug c++/20414] C-style cast fails to do proper conversion (explicit type conversion)
--- Additional Comments From pcarlini at suse dot de 2005-03-10 21:19 --- Seems already fixed in mainline and 4_0-branch... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20414
[Bug c++/20414] C-style cast fails to do proper conversion (explicit type conversion)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10 21:23 --- Fixed in 4.0.0 by: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01676.html >From that patch: "The underlying problem was that we were not handling C-style casts as one of const_cast, static_cast, or reinterpret_cast as required by the standard. (There are a few extra bits, but that's the basic idea.) So, I fixed that." -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||wrong-code Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20414
[Bug target/20322] [4.0/4.1 Regression] Miscompilation of libcpp/expr.c at -O2+
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-10 21:26 --- Subject: Bug 20322 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-10 21:26:12 Modified files: gcc: ChangeLog combine.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20050307-1.c Log message: PR target/20322 * combine.c (try_combine): If recog_for_combine added CLOBBERs to NEWI2PAT, fail to combine if they are used by NEWPAT. * gcc.dg/20050307-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7775&r2=2.7776 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/combine.c.diff?cvsroot=gcc&r1=1.478&r2=1.479 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5138&r2=1.5139 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050307-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20322
[Bug target/20322] [4.0/4.1 Regression] Miscompilation of libcpp/expr.c at -O2+
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-10 21:30 --- Subject: Bug 20322 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-10 21:29:56 Modified files: gcc: ChangeLog combine.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20050307-1.c Log message: PR target/20322 * combine.c (try_combine): If recog_for_combine added CLOBBERs to NEWI2PAT, fail to combine if they are used by NEWPAT. * gcc.dg/20050307-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.39&r2=2.7592.2.40 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/combine.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.475&r2=1.475.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.33&r2=1.5084.2.34 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050307-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20322
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From ericw at evcohs dot com 2005-03-10 21:30 --- Marek, can you review this bug, the attached patches, and possibly approve committing the fix? Thanks Eric -- What|Removed |Added CC||marekm at amelek dot gda dot ||pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
[Bug target/20322] [4.0/4.1 Regression] Miscompilation of libcpp/expr.c at -O2+
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-10 21:31 --- Fixed in CVS. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20322
