[Bug target/28995] [4.2 Regression] libgfortran build now fails on Darwin PPC
--- Comment #14 from echristo at gcc dot gnu dot org 2006-09-10 07:09 --- Subject: Bug 28995 Author: echristo Date: Sun Sep 10 07:09:38 2006 New Revision: 116810 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116810 Log: 2006-09-09 Eric Christopher <[EMAIL PROTECTED]> PR target/28995 * config/darwin.c (machopic_select_rtx_section): Add TARGET_64BIT for literal16. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28995
[Bug target/28995] [4.2 Regression] libgfortran build now fails on Darwin PPC
--- Comment #15 from echristo at apple dot com 2006-09-10 07:11 --- So, just committed a patch for the 32-bit problems with literal16 sections. (No, they won't be valid for 32-bit.) I'm holding on the configure patch since 2.4 seems to work fine with the patch for people and I find it reasonable to assume that people will download that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28995
[Bug target/27681] [4.1 regression] Missing DImode float conversion functions with -msoft-float
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-09-10 07:13 --- Subject: Bug 27681 Author: rsandifo Date: Sun Sep 10 07:13:12 2006 New Revision: 116811 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116811 Log: gcc/ PR target/27681 Backport from mainline: 2006-05-23 Richard Sandiford <[EMAIL PROTECTED]> * libgcc2.c (LIBGCC2_MAX_UNITS_PER_WORD): New macro. (LIBGCC2_UNITS_PER_WORD): Use LIBGCC2_MAX_UNITS_PER_WORD rather than MIN_UNITS_PER_WORD to set the default. Also use it in the guard. 2006-05-22 Richard Sandiford <[EMAIL PROTECTED]> * mklibgcc.in (lib2funcs): Remove _floatdidf from initial assignment. 2006-05-19 Richard Sandiford <[EMAIL PROTECTED]> * libgcc2.c (MIN_UNITS_PER_WORD): Move default definition from libgcc2.h. (LIBGCC2_UNITS_PER_WORD): Provide default definition, using old MIN_UNITS_PER_WORD logic from libgcc2.h. Do nothing if LIBGCC2_UNITS_PER_WORD > MIN_UNITS_PER_WORD. * libgcc2.h (MIN_UNITS_PER_WORD): Remove definition from here. Use LIBGCC2_UNITS_PER_WORD rather than MIN_UNITS_PER_WORD to determine the size of Wtype, etc. * mklibgcc.in (LIB2_SIDITI_CONV_FUNCS): New argument. (swfloatfuncs): New variable. (dwfloatfuncs): Likewise. (lib2funcs): Remove floating-point conversion functions from initial assignment. Use LIB2_SIDITI_CONV_FUNCS to determine the set of conversion routines needed. Allow entries to specify an object name, filename and word size. Update users accordingly. * Makefile.in (libgcc.mk): Pass LIB2_SIDITI_CONV_FUNCS. * config/mips/t-mips (LIB2_SIDITI_CONV_FUNCS): Define. Revert: 2006-02-08 Roger Sayle <[EMAIL PROTECTED]> PR target/22209 * config/fixtfdi.c: New libgcc source file. * config/fixunstfdi.c: New source file. * config/floatditf.c: New source file. * config/floatunditf.c: New souce file. * config/mips/t-iris6 (LIB2FUNCS_EXTRA): Include the new source files above instead of config/mips/_tilib.c. * config/mips/t-linux64 (LIB2FUNCS_EXTRA): Likewise. Removed: branches/gcc-4_1-branch/gcc/config/fixtfdi.c branches/gcc-4_1-branch/gcc/config/fixunstfdi.c branches/gcc-4_1-branch/gcc/config/floatditf.c branches/gcc-4_1-branch/gcc/config/floatunditf.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/Makefile.in branches/gcc-4_1-branch/gcc/config/mips/t-iris6 branches/gcc-4_1-branch/gcc/config/mips/t-linux64 branches/gcc-4_1-branch/gcc/config/mips/t-mips branches/gcc-4_1-branch/gcc/libgcc2.c branches/gcc-4_1-branch/gcc/libgcc2.h branches/gcc-4_1-branch/gcc/mklibgcc.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27681
[Bug target/22209] [4.1 regression] libgfortran unresolvable symbols on irix6.5
--- Comment #15 from rsandifo at gcc dot gnu dot org 2006-09-10 07:13 --- Subject: Bug 22209 Author: rsandifo Date: Sun Sep 10 07:13:12 2006 New Revision: 116811 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116811 Log: gcc/ PR target/27681 Backport from mainline: 2006-05-23 Richard Sandiford <[EMAIL PROTECTED]> * libgcc2.c (LIBGCC2_MAX_UNITS_PER_WORD): New macro. (LIBGCC2_UNITS_PER_WORD): Use LIBGCC2_MAX_UNITS_PER_WORD rather than MIN_UNITS_PER_WORD to set the default. Also use it in the guard. 2006-05-22 Richard Sandiford <[EMAIL PROTECTED]> * mklibgcc.in (lib2funcs): Remove _floatdidf from initial assignment. 2006-05-19 Richard Sandiford <[EMAIL PROTECTED]> * libgcc2.c (MIN_UNITS_PER_WORD): Move default definition from libgcc2.h. (LIBGCC2_UNITS_PER_WORD): Provide default definition, using old MIN_UNITS_PER_WORD logic from libgcc2.h. Do nothing if LIBGCC2_UNITS_PER_WORD > MIN_UNITS_PER_WORD. * libgcc2.h (MIN_UNITS_PER_WORD): Remove definition from here. Use LIBGCC2_UNITS_PER_WORD rather than MIN_UNITS_PER_WORD to determine the size of Wtype, etc. * mklibgcc.in (LIB2_SIDITI_CONV_FUNCS): New argument. (swfloatfuncs): New variable. (dwfloatfuncs): Likewise. (lib2funcs): Remove floating-point conversion functions from initial assignment. Use LIB2_SIDITI_CONV_FUNCS to determine the set of conversion routines needed. Allow entries to specify an object name, filename and word size. Update users accordingly. * Makefile.in (libgcc.mk): Pass LIB2_SIDITI_CONV_FUNCS. * config/mips/t-mips (LIB2_SIDITI_CONV_FUNCS): Define. Revert: 2006-02-08 Roger Sayle <[EMAIL PROTECTED]> PR target/22209 * config/fixtfdi.c: New libgcc source file. * config/fixunstfdi.c: New source file. * config/floatditf.c: New source file. * config/floatunditf.c: New souce file. * config/mips/t-iris6 (LIB2FUNCS_EXTRA): Include the new source files above instead of config/mips/_tilib.c. * config/mips/t-linux64 (LIB2FUNCS_EXTRA): Likewise. Removed: branches/gcc-4_1-branch/gcc/config/fixtfdi.c branches/gcc-4_1-branch/gcc/config/fixunstfdi.c branches/gcc-4_1-branch/gcc/config/floatditf.c branches/gcc-4_1-branch/gcc/config/floatunditf.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/Makefile.in branches/gcc-4_1-branch/gcc/config/mips/t-iris6 branches/gcc-4_1-branch/gcc/config/mips/t-linux64 branches/gcc-4_1-branch/gcc/config/mips/t-mips branches/gcc-4_1-branch/gcc/libgcc2.c branches/gcc-4_1-branch/gcc/libgcc2.h branches/gcc-4_1-branch/gcc/mklibgcc.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22209
[Bug target/27681] Missing DImode float conversion functions with -msoft-float
--- Comment #7 from rsandifo at gcc dot gnu dot org 2006-09-10 07:17 --- Patch committed. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.0.0 4.1.0 4.2.0 |4.0.0 4.1.0 4.1.2 4.2.0 Resolution||FIXED Summary|[4.1 regression] Missing|Missing DImode float |DImode float conversion |conversion functions with - |functions with -msoft-float |msoft-float http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27681
[Bug testsuite/28950] regex wrong for gcc/testsuite/gcc.target/powerpc/ppc-and-1.c
--- Comment #1 from echristo at apple dot com 2006-09-10 07:18 --- But wouldn't that change make it fail on platforms that don't want an "r"? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28950
[Bug testsuite/28950] regex wrong for gcc/testsuite/gcc.target/powerpc/ppc-and-1.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-10 07:21 ---
(In reply to comment #1)
> But wouldn't that change make it fail on platforms that don't want an "r"?
Does {,r} work for regex in dejagnu tests?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28950
[Bug target/28995] [4.2 Regression] libgfortran build now fails on Darwin PPC
--- Comment #16 from echristo at apple dot com 2006-09-10 07:48 --- I believe this is fixed with the above change. -- echristo at apple dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28995
[Bug c++/28266] [4.0/4.1/4.2 regression] ICE on invalid default variable
--- Comment #2 from patchapp at dberlin dot org 2006-09-10 07:55 --- Subject: Bug number PR c++/28266 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00367.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28266
[Bug c++/28999] New: [4.0/4.1/4.2 regression] ICE on invalid use of typename
The following invalid code snippet triggers an ICE since GCC 3.4.0:
==
namespace N
{
template void foo();
}
template struct A
{
friend void typename N::foo<0>();
};
==
bug.cc:8: internal compiler error: in make_typename_type, at cp/decl.c:2818
Please submit a full bug report, [etc.]
--
Summary: [4.0/4.1/4.2 regression] ICE on invalid use of typename
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28999
[Bug c++/28999] [4.0/4.1/4.2 regression] ICE on invalid use of typename
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28999
[Bug c++/29000] New: [4.2 regression] ICE on invalid use of template in statement-expr
The following invalid code snippet triggers an ICE on mainline:
template int foo()
{
return ({foo;})==0;
}
bug.cc: In function 'int foo()':
bug.cc:3: internal compiler error: in type_dependent_expression_p, at
cp/pt.c:12955
Please submit a full bug report, [etc.]
--
Summary: [4.2 regression] ICE on invalid use of template in
statement-expr
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29000
[Bug c++/29000] [4.2 regression] ICE on invalid use of template in statement-expr
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29000
[Bug c++/29001] New: ICE on invalid return from operator new
The following invalid code snippet triggers an ICE since at least GCC 2.95.3:
===
void* operator new (__SIZE_TYPE__) { return; }
===
bug.cc: In function 'void* operator new(unsigned int)':
bug.cc:1: error: return-statement with no value, in function returning 'void*'
bug.cc:1: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: ICE on invalid return from operator new
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29001
[Bug c++/29002] New: [4.0/4.1/4.2 regression] ICE on array of ptr-to-member of unknown size
The following invalid code snippet triggers an ICE since GCC 3.3:
struct A {};
int A::* x[];
bug.cc:2: internal compiler error: in build_zero_init, at cp/init.c:226
Please submit a full bug report, [etc.]
--
Summary: [4.0/4.1/4.2 regression] ICE on array of ptr-to-member
of unknown size
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29002
[Bug c++/29002] [4.0/4.1/4.2 regression] ICE on array of ptr-to-member of unknown size
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29002
[Bug c++/29003] New: operator name accepted in typedef
The following invalid code snippet is accepted since at least GCC 2.95.3:
typedef int operator! ();
With such a broken declaration it's easy to crash the compiler afterwards:
struct A {};
typedef int operator! (A);
int i = !A();
bug.cc:3: error: argument dependent lookup finds 'operator!'
bug.cc:5: error: in call to 'operator!'
bug.cc:5: internal compiler error: tree check: expected function_type or
method_type, have error_mark in add_function_candidate, at cp/call.c:1327
Please submit a full bug report, [etc.]
--
Summary: operator name accepted in typedef
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, accepts-invalid, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29003
[Bug middle-end/26983] [4.0/4.1/4.2 Regression] Missing label with builtin_setjmp/longjmp
--- Comment #9 from steven at gcc dot gnu dot org 2006-09-10 10:59 --- In GCC3, the label is not removed because it is in label_value_list. In GCC4 we don't have that list anymore. That means we have to trust LABEL_NUSES, or we have to force preservation of the label via LABEL_PRESERVE_P. I'm inclined to go with the former, but LABEL_NUSES is notoriously unreliable so I'm not entirely comfortable with using it... :-/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26983
[Bug middle-end/26983] [4.0/4.1/4.2 Regression] Missing label with builtin_setjmp/longjmp
--- Comment #10 from steven at gcc dot gnu dot org 2006-09-10 11:16 --- I've decided to go with LABEL_PRESERVE_P after all... Index: builtins.c === --- builtins.c (revision 116785) +++ builtins.c (working copy) @@ -760,6 +760,12 @@ expand_builtin_setjmp (tree arglist, rtx emit_label (next_lab); + /* Because setjmp and longjmp are not represented in the CFG, a cfgcleanup + may find that the basic block starting with NEXT_LAB is unreachable. + The whole block, along with NEXT_LAB, would be removed. Make sure that + never happens. */ + LABEL_PRESERVE_P (next_lab) = 1; + expand_builtin_setjmp_receiver (next_lab); /* Set TARGET to one. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26983
[Bug tree-optimization/28887] [4.2 Regression] rejects valid code (bitfields and loops) with -O1 -fprefetch-loop-arrays
--- Comment #6 from steven at gcc dot gnu dot org 2006-09-10 11:56 --- Patch was approved, but Zdenek still has to commit it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28887
[Bug rtl-optimization/28965] distribute_notes fails to change REG_DEAD into REG_UNUSED notes for global registers
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-09-10 12:12 --- Please provide a testcase as well as the other required bits of info. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28965
[Bug rtl-optimization/28726] [4.1 regression] -fsched2-use-superblock produces wrong code
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-09-10 12:26 --- Works with 4.0.4pre so regression on 4.1 branch. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|gcc-4.1.1/vanilla |i686-pc-linux-gnu Known to fail||4.1.2 Known to work||4.0.4 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-09-10 12:26:19 date|| Summary|-fsched2-use-superblock |[4.1 regression] -fsched2- |produces wrong code |use-superblock produces ||wrong code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28726
[Bug rtl-optimization/28726] [4.1 regression] -fsched2-use-superblock produces wrong code
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-09-10 12:26 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-10 12:26:19 |2006-09-10 12:26:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28726
[Bug tree-optimization/23955] [4.0/4.1/4.2 Regression] Compile time regressions with tramp3d
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-09-10 13:24 --- Compile time is reasonable again, memory usage regressions are just tree-ssa, we have plenty of other PRs for this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.0.3 4.1.0 Known to work||4.2.0 4.1.2 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23955
[Bug c++/29004] New: Wrong Code for ARM IRQ routine
Compiling the code:
extern void doSomething(unsigned v);
void irq_() __attribute__ ((interrupt("IRQ")));
void irq_()
{
unsigned v;
doSomething(v);
}
with:
arm-elf-g++ -O0\
-fno-exceptions\
-fomit-frame-pointer\
-S -o irq-bug.s\
irq-bug.cc
results in:
.file "irq-bug.cc"
.text
.align 2
.global _Z4irq_v
.type _Z4irq_v, %function
_Z4irq_v:
@ Interrupt Service Routine.
@ args = 0, pretend = 0, frame = 4
@ frame_needed = 0, uses_anonymous_args = 0
sub lr, lr, #4@<--- (1)
stmfd sp!, {r0, r1, r2, r3, ip, lr}
sub sp, sp, #4
ldr r0, [sp, #0]
bl _Z11doSomethingj
add sp, sp, #4
ldmfd sp!, {r0, r1, r2, r3, ip, lr}
subspc, lr, #4@<--- (2)
.size _Z4irq_v, .-_Z4irq_v
.ident "GCC: (GNU) 4.1.1"
Remarks:
- the lr register is decremented twice (1) (2)
- the -O0 and -fomit-frame-pointer switches are relevant
- arm-elf-g++ -v:
Using built-in specs.
Target: arm-elf
Configured with:
/home/buchmann/devel/gcc/dist/gcc-4.1.1/configure -v
--prefix=/home/buchmann/devel/gcc/targets/arm/
--target=arm-elf --enable-languages=c,c++,java
--disable-threads
--disable-shared
--disable-multilib
--with-as=/home/buchmann/devel/gcc/targets/arm/arm-elf/bin/as
--with-ld=/home/buchmann/devel/gcc/targets/arm/arm-elf/bin/ld
--with-newlib
--without-headers
Thread model: single
gcc version 4.1.1
Best regards
Hans Buchmann
--
Summary: Wrong Code for ARM IRQ routine
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hans dot buchmann at fhso dot ch
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29004
[Bug c++/28999] [4.0/4.1/4.2 regression] ICE on invalid use of typename
-- steven at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Last reconfirmed|-00-00 00:00:00 |2006-09-10 13:50:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28999
[Bug c++/29002] [4.0/4.1/4.2 regression] ICE on array of ptr-to-member of unknown size
-- steven at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Last reconfirmed|-00-00 00:00:00 |2006-09-10 13:50:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29002
[Bug c++/29000] [4.2 regression] ICE on invalid use of template in statement-expr
-- steven at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Last reconfirmed|-00-00 00:00:00 |2006-09-10 13:50:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29000
[Bug c++/28999] [4.0/4.1/4.2 regression] ICE on invalid use of typename
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|2006-09-10 13:50:31 |2006-09-10 13:50:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28999
[Bug c++/29000] [4.2 regression] ICE on invalid use of template in statement-expr
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|2006-09-10 13:50:32 |2006-09-10 13:51:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29000
[Bug c++/29002] [4.0/4.1/4.2 regression] ICE on array of ptr-to-member of unknown size
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|2006-09-10 13:50:32 |2006-09-10 13:51:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29002
[Bug middle-end/28958] Compiling vpnc with GCC 4.1 and anything other than -O0 causes failure to connect
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-10 14:31 --- This still should be waiting for a testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28958
[Bug testsuite/28950] regex wrong for testing on darwin in gcc/testsuite/gcc.target/powerpc/ppc-and-1.c
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-10 14:35 --- Confirmed, a minor problem with the testsuite. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc-apple-darwin8 | GCC host triplet|powerpc-apple-darwin8 | GCC target triplet|powerpc-apple-darwin8 |powerpc*-*-darwin* Last reconfirmed|-00-00 00:00:00 |2006-09-10 14:35:45 date|| Summary|regex wrong for |regex wrong for testing on |gcc/testsuite/gcc.target/pow|darwin in |erpc/ppc-and-1.c|gcc/testsuite/gcc.target/pow ||erpc/ppc-and-1.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28950
[Bug c++/28999] [4.0/4.1/4.2 regression] ICE on invalid use of typename
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-10 14:38 --- 3.2.3 gave: t.cc:8: syntax error before `<' token Which is just as helpful as the ICE anyways. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28999
[Bug c++/29000] [4.2 regression] ICE on invalid use of template in statement-expr
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-10 14:40 --- 3.2.3 just slightly accepted this code. 4.1.x gave the following error message: t.cc:3: error: overloaded function with no contextual type information t.cc:3: error: void value not ignored as it ought to be Where the second error message is bogus. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29000
[Bug fortran/28914] Code inside loop hangs; outside loop runs normally; runs OK on other compilers
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28914
[Bug c++/29002] [4.0/4.1/4.2 regression] ICE on array of ptr-to-member or struct containing ptr-to-member of unknown size
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-10 15:41 ---
Another testcase:
struct A {A();int A::* t;};
A x[];
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1/4.2 regression] ICE
|on array of ptr-to-member of|on array of ptr-to-member or
|unknown size|struct containing ptr-to-
||member of unknown size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29002
[Bug c++/29002] [4.0/4.1/4.2 regression] ICE on array of ptr-to-member or struct containing ptr-to-member of unknown size
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-10 15:50 --- I have a fix for both testcases, the problem is the same. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29002
[Bug ada/21952] [4.1/4.2 regression] Annoying "attribute directive ignored" warnings
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
[Bug libmudflap/28077] [4.1/4.2 regression] pass39-frag.c produces mudflap violation on alpha
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28077
[Bug target/28183] [4.0/4.1/4.2 regression] assembler error "FATAL: can't close x.o" on m68k with new binutils
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28183
[Bug target/28307] [4.1/4.2 Regression] pthread functions in libgcc not weak any more on Tru64 UNIX
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28307
[Bug bootstrap/28326] [4.1 regression] profiledbootstrap will produce an ICE with "-mtune=power3 -mcpu=power3" in BOOT_CFLAGS
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28326
[Bug target/28376] [4.1 Regression] ICE when building opensp with -O3 on alpha
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28376
[Bug middle-end/28463] [4.0/4.1/4.2 Regression] Using -fdump-tree-optimized causes a huge compile time memory regression
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28463
[Bug rtl-optimization/28726] [4.1 regression] -fsched2-use-superblock produces wrong code
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28726
[Bug java/28754] [4.2 regression] java.lang.nullPointerException while accessing final static members of an interface
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28754
[Bug other/28781] [4.2 regression] -fPIC generates non-PIC code
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28781
[Bug c++/28827] [4.0 Regression] ICE with nested template friend
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28827
[Bug bootstrap/28949] [4.2 regression] configure-target-libiberty: Link tests are not allowed after GCC_NO_EXECUTABLES
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
[Bug fortran/28923] Bad triplet interpretation in initialization
--- Comment #3 from pault at gcc dot gnu dot org 2006-09-10 17:13 --- Subject: Bug 28923 Author: pault Date: Sun Sep 10 17:13:29 2006 New Revision: 116815 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116815 Log: 2006-09-10 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28923 expr.c (find_array_section): Only use the array lower and upper bounds for the start and end of the sections, where the expr is NULL. 2006-09-10 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28923 gfortran.dg/array_initializer_2.f90: Fill in missing index start value. gfortran.dg/array_initializer_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_initializer_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/array_initializer_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28923
[Bug fortran/28959] ICE on derived type with host association
--- Comment #4 from pault at gcc dot gnu dot org 2006-09-10 17:18 --- Subject: Bug 28959 Author: pault Date: Sun Sep 10 17:17:57 2006 New Revision: 116816 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116816 Log: 2006-09-10 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28959 trans-types.c (gfc_get_derived_type): Use the parent namespace of the procedure if the type's own namespace does not have a parent. 2006-09-10 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28959 gfortran.dg/used_types_10: New test. Added: trunk/gcc/testsuite/gfortran.dg/used_types_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28959
[Bug fortran/28947] Double MATMUL() uses wrong array elements
--- Comment #3 from pault at gcc dot gnu dot org 2006-09-10 17:21 --- Subject: Bug 28947 Author: pault Date: Sun Sep 10 17:21:44 2006 New Revision: 116817 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116817 Log: 2006-09-10 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28947 * m4/matmul.m4: For the case where the second input argument is transposed, ensure that the case with rank (a) == 1 is correctly calculated. * generated/matmul_r4.c: Regenerate. * generated/matmul_r8.c: Regenerate. * generated/matmul_r10.c: Regenerate. * generated/matmul_r16.c: Regenerate. * generated/matmul_c4.c: Regenerate. * generated/matmul_c8.c: Regenerate. * generated/matmul_c10.c: Regenerate. * generated/matmul_c16.c: Regenerate. * generated/matmul_i4.c: Regenerate. * generated/matmul_i8.c: Regenerate. * generated/matmul_i16.c: Regenerate. 2006-09-10 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28947 gfortran.dg/matmul_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/matmul_4.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/matmul_c10.c trunk/libgfortran/generated/matmul_c16.c trunk/libgfortran/generated/matmul_c4.c trunk/libgfortran/generated/matmul_c8.c trunk/libgfortran/generated/matmul_i16.c trunk/libgfortran/generated/matmul_i4.c trunk/libgfortran/generated/matmul_i8.c trunk/libgfortran/generated/matmul_r10.c trunk/libgfortran/generated/matmul_r16.c trunk/libgfortran/generated/matmul_r4.c trunk/libgfortran/generated/matmul_r8.c trunk/libgfortran/m4/matmul.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28947
[Bug fortran/28947] Double MATMUL() uses wrong array elements
--- Comment #4 from pault at gcc dot gnu dot org 2006-09-10 17:27 --- Subject: Bug 28947 Author: pault Date: Sun Sep 10 17:26:54 2006 New Revision: 116818 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116818 Log: 2006-09-10 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28947 * m4/matmul.m4: For the case where the second input argument is transposed, ensure that the case with rank (a) == 1 is correctly calculated. * generated/matmul_r4.c: Regenerate. * generated/matmul_r8.c: Regenerate. * generated/matmul_r10.c: Regenerate. * generated/matmul_r16.c: Regenerate. * generated/matmul_c4.c: Regenerate. * generated/matmul_c8.c: Regenerate. * generated/matmul_c10.c: Regenerate. * generated/matmul_c16.c: Regenerate. * generated/matmul_i4.c: Regenerate. * generated/matmul_i8.c: Regenerate. * generated/matmul_i16.c: Regenerate. 2006-09-10 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28947 gfortran.dg/matmul_4.f90: New test. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/fortran/trans-types.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/array_initializer_2.f90 branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/generated/matmul_c10.c branches/gcc-4_1-branch/libgfortran/generated/matmul_c16.c branches/gcc-4_1-branch/libgfortran/generated/matmul_c4.c branches/gcc-4_1-branch/libgfortran/generated/matmul_c8.c branches/gcc-4_1-branch/libgfortran/generated/matmul_i16.c branches/gcc-4_1-branch/libgfortran/generated/matmul_i4.c branches/gcc-4_1-branch/libgfortran/generated/matmul_i8.c branches/gcc-4_1-branch/libgfortran/generated/matmul_r10.c branches/gcc-4_1-branch/libgfortran/generated/matmul_r16.c branches/gcc-4_1-branch/libgfortran/generated/matmul_r4.c branches/gcc-4_1-branch/libgfortran/generated/matmul_r8.c branches/gcc-4_1-branch/libgfortran/m4/matmul.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28947
[Bug fortran/28959] ICE on derived type with host association
--- Comment #5 from pault at gcc dot gnu dot org 2006-09-10 17:32 --- Subject: Bug 28959 Author: pault Date: Sun Sep 10 17:32:22 2006 New Revision: 116819 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116819 Log: 2006-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28923 expr.c (find_array_section): Only use the array lower and upper bounds for the start and end of the sections, where the expr is NULL. PR fortran/28959 trans-types.c (gfc_get_derived_type): Use the parent namespace of the procedure if the type's own namespace does not have a parent. 2006-09-09 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28947 * m4/matmul.m4: For the case where the second input argument is transposed, ensure that the case with rank (a) == 1 is correctly calculated. * generated/matmul_r4.c: Regenerate. * generated/matmul_r8.c: Regenerate. * generated/matmul_r10.c: Regenerate. * generated/matmul_r16.c: Regenerate. * generated/matmul_c4.c: Regenerate. * generated/matmul_c8.c: Regenerate. * generated/matmul_c10.c: Regenerate. * generated/matmul_c16.c: Regenerate. * generated/matmul_i4.c: Regenerate. * generated/matmul_i8.c: Regenerate. * generated/matmul_i16.c: Regenerate. 2006-09-09 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28923 gfortran.dg/array_initializer_2.f90: Fill in missing index start value. gfortran.dg/array_initializer_3.f90: New test. PR libfortran/28947 gfortran.dg/matmul_4.f90: New test. PR fortran/28959 gfortran.dg/used_types_10: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/array_initializer_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/matmul_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_10.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28959
[Bug fortran/28947] Double MATMUL() uses wrong array elements
--- Comment #5 from pault at gcc dot gnu dot org 2006-09-10 17:32 --- Subject: Bug 28947 Author: pault Date: Sun Sep 10 17:32:22 2006 New Revision: 116819 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116819 Log: 2006-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28923 expr.c (find_array_section): Only use the array lower and upper bounds for the start and end of the sections, where the expr is NULL. PR fortran/28959 trans-types.c (gfc_get_derived_type): Use the parent namespace of the procedure if the type's own namespace does not have a parent. 2006-09-09 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28947 * m4/matmul.m4: For the case where the second input argument is transposed, ensure that the case with rank (a) == 1 is correctly calculated. * generated/matmul_r4.c: Regenerate. * generated/matmul_r8.c: Regenerate. * generated/matmul_r10.c: Regenerate. * generated/matmul_r16.c: Regenerate. * generated/matmul_c4.c: Regenerate. * generated/matmul_c8.c: Regenerate. * generated/matmul_c10.c: Regenerate. * generated/matmul_c16.c: Regenerate. * generated/matmul_i4.c: Regenerate. * generated/matmul_i8.c: Regenerate. * generated/matmul_i16.c: Regenerate. 2006-09-09 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28923 gfortran.dg/array_initializer_2.f90: Fill in missing index start value. gfortran.dg/array_initializer_3.f90: New test. PR libfortran/28947 gfortran.dg/matmul_4.f90: New test. PR fortran/28959 gfortran.dg/used_types_10: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/array_initializer_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/matmul_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_10.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28947
[Bug fortran/28923] Bad triplet interpretation in initialization
--- Comment #4 from pault at gcc dot gnu dot org 2006-09-10 17:32 --- Subject: Bug 28923 Author: pault Date: Sun Sep 10 17:32:22 2006 New Revision: 116819 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116819 Log: 2006-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/28923 expr.c (find_array_section): Only use the array lower and upper bounds for the start and end of the sections, where the expr is NULL. PR fortran/28959 trans-types.c (gfc_get_derived_type): Use the parent namespace of the procedure if the type's own namespace does not have a parent. 2006-09-09 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28947 * m4/matmul.m4: For the case where the second input argument is transposed, ensure that the case with rank (a) == 1 is correctly calculated. * generated/matmul_r4.c: Regenerate. * generated/matmul_r8.c: Regenerate. * generated/matmul_r10.c: Regenerate. * generated/matmul_r16.c: Regenerate. * generated/matmul_c4.c: Regenerate. * generated/matmul_c8.c: Regenerate. * generated/matmul_c10.c: Regenerate. * generated/matmul_c16.c: Regenerate. * generated/matmul_i4.c: Regenerate. * generated/matmul_i8.c: Regenerate. * generated/matmul_i16.c: Regenerate. 2006-09-09 Paul Thomas <[EMAIL PROTECTED]> PR libfortran/28923 gfortran.dg/array_initializer_2.f90: Fill in missing index start value. gfortran.dg/array_initializer_3.f90: New test. PR libfortran/28947 gfortran.dg/matmul_4.f90: New test. PR fortran/28959 gfortran.dg/used_types_10: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/array_initializer_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/matmul_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_10.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28923
[Bug testsuite/27707] g++.dg/tree-ssa/ivopts-1.C fails
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-10 18:39 --- Subject: Re: g++.dg/tree-ssa/ivopts-1.C fails > The linux output doesn't have the -4 offset: > >ldi 1,%r28 >stw %r2,-20(%r30) > .LCFI0: >copy %r28,%r21 >ldo 128(%r30),%r30 > .LCFI1: >ldi 4,%r19 >stw %r28,-120(%r30) >ldo -120(%r30),%r26 >ldi 16,%r20 > .L2: >addl %r19,%r26,%r28 >ldo 4(%r19),%r19 >comb,<> %r20,%r19,.L2 >stw %r21,0(%r28) >bl _Z3fooR3Foo,%r2 >nop It seems like the code generated for the hppa-unknown-linux-gnu target has been getting worse in each release since 4.0.0. Here is the 4.0.0 assembler code: stw %r2,-20(%r30) .LCFI0: ldi 1,%r19 ldo 128(%r30),%r30 .LCFI1: ldo -120(%r30),%r28 ldo -104(%r30),%r20 stw %r19,0(%r28) .L8: ldo 4(%r28),%r28 comb,<>,n %r28,%r20,.L8 stw %r19,0(%r28) bl _Z3fooR3Foo,%r2 ldo -120(%r30),%r26 In this code, the function prologue and loop setup are only six instructions. The loop is three instructions. The delay slot for the call to _Z3fooR3Foo is filled. The value loaded into r26 is the same as loaded into r28 before the loop. I would say this code is close to optimal aside from unrolling loop completely. Here is the code generated by Debian 4.1.1-13: stw %r2,-20(%r30) .LCFI0: ldi 0,%r19 ldo 128(%r30),%r30 .LCFI1: ldi 1,%r21 ldo -120(%r30),%r26 ldi 16,%r20 .L2: addl %r19,%r26,%r28 ldo 4(%r19),%r19 comb,<> %r20,%r19,.L2 stw %r21,0(%r28) bl _Z3fooR3Foo,%r2 nop The prologue and loop setup are still six instructions. However, the loop is now four instructions per iteration and we iterate one more time. Thus, we have a significant performance regression relative to 4.0.0 in the handling of this loop. Possibly, this results from the compiler trying to avoid loading the address "-120(%r30)" twice. However, the cost for loading small offsets is the same as doing a register copy. A register copy is just a ldo instruction with an offset of 0. The 4.2.0 code is worse than the 4.1.1 code in that the prologue and loop setup have now grown to eight instructions. However, we are back to three iterations. It seems like the compiler may be trying to avoid non-zero offsets. I don't know why this would be. hppa_address_cost is pretty simple. As far as the the difference between linux and hpux goes, the main difference is that long doubles are 64 bits on linux and 128 bits on hpux. This would affect the sizes of the cost arrays in expmed.c. I'm wondering if somehow some of the values in these tables are getting corrupted. There's one puzzling difference in the linux and hpux tree dumps. In the hpux dump, some variables are "long unsigned int" whereas in the linux dump they are "unsigned int". Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27707
[Bug middle-end/26983] [4.0/4.1/4.2 Regression] Missing label with builtin_setjmp/longjmp
--- Comment #11 from patchapp at dberlin dot org 2006-09-10 18:40 --- Subject: Bug number PR26983 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00370.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26983
[Bug libfortran/29005] New: cast from pointer to integer of different size in libgfortran/intrinsics/signal.c
When libgfortran/intrinsics/signal.c is built at -m64, a number of warnings occur... /sw/src/fink.build/gcc4-4.1.999-20060910/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.999-20060910/darwin_objdir/./gcc/ -B/sw/lib/gcc4/powerpc-apple-darwin8/bin/ -B/sw/lib/gcc4/powerpc-apple-darwin8/lib/ -isystem /sw/lib/gcc4/powerpc-apple-darwin8/include -isystem /sw/lib/gcc4/powerpc-apple-darwin8/sys-include -DHAVE_CONFIG_H -I. -I../../../../gcc-4.2-20060910/libgfortran -I. -iquote../../../../gcc-4.2-20060910/libgfortran/io -I../../../../gcc-4.2-20060910/libgfortran/../gcc -I../../../../gcc-4.2-20060910/libgfortran/../gcc/config -I../../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2 -m64 -c ../../../../gcc-4.2-20060910/libgfortran/intrinsics/signal.c -fno-common -DPIC -o .libs/signal.o ../../../../gcc-4.2-20060910/libgfortran/intrinsics/signal.c: In function 'signal_sub': ../../../../gcc-4.2-20060910/libgfortran/intrinsics/signal.c:52: warning: cast from pointer to integer of different size ../../../../gcc-4.2-20060910/libgfortran/intrinsics/signal.c: In function 'signal_sub_int': ../../../../gcc-4.2-20060910/libgfortran/intrinsics/signal.c:73: warning: cast to pointer from integer of different size ../../../../gcc-4.2-20060910/libgfortran/intrinsics/signal.c:73: warning: cast from pointer to integer of different size ../../../../gcc-4.2-20060910/libgfortran/intrinsics/signal.c:75: warning: cast to pointer from integer of different size corresponding to the lines... *status = (int) signal (*number, handler); *status = (int) signal (*number, (void (*)(int)) *handler); signal (*number, (void (*)(int)) *handler); from the subroutine... void signal_sub (int *number, void (*handler)(int), int *status) ...for the first warning and from the subroutine... void signal_sub_int (int *number, int *handler, int *status) Note: Thomas Koenig comments that since signal() returns a pointer to the previous signal handle and g77 uses an integer variable wide enough to hold the STATUS argument, we should do the same. -- Summary: cast from pointer to integer of different size in libgfortran/intrinsics/signal.c Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: powerpc-apple-darwin8 GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29005
[Bug libfortran/29005] cast from pointer to integer of different size in libgfortran/intrinsics/signal.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-10 18:55 --- *** This bug has been marked as a duplicate of 26540 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29005
[Bug libfortran/26540] some gcc-4.1.0/libgfortran/intrinsics/signal.c warning: cast from/to pointer to/from integer of different size on x86-64
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-10 18:55 --- *** Bug 29005 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||howarth at nitro dot med dot ||uc dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26540
[Bug libfortran/26540] some gcc-4.1.0/libgfortran/intrinsics/signal.c warning: cast from/to pointer to/from integer of different size on x86-64
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2006-09-10 19:04 --- Andrew, The comment... These warnings are semi expected in that signal is expected not to work with 64bit, this is due to g77 compatibility. ..is confusing. If this is the case, why don't we use preprocessor statements to detect the 64-bit builds and eliminate the warning in those cases only. Especially as I don't think the warnings occur in 32-bit builds of libgfortran. Is there really any legacy g77 code built at 64-bit to support? Jack -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26540
[Bug target/29006] New: Incorrect zeroing of unaligned 64-bit fields on MIPS targets
gcc will use swl/swr instead of sdl/sdr to zero an unaligned
64-bit field. This can be seem with a testcase like:
struct __attribute__((__packed__)) s { char c; unsigned long long x; };
void __attribute__((__noinline__)) foo (struct s *s) { s->x = 0; }
int main (void) { struct s s = { 1, ~0ULL }; foo (&s); return s.x != 0; }
--
Summary: Incorrect zeroing of unaligned 64-bit fields on MIPS
targets
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rsandifo at gcc dot gnu dot org
GCC target triplet: mipsisa64-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29006
[Bug target/29006] Incorrect zeroing of unaligned 64-bit fields on MIPS targets
--- Comment #1 from rsandifo at gcc dot gnu dot org 2006-09-10 19:08 --- I'm about to commit a fix. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.3 4.1.1 4.2.0 Known to work||3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29006
[Bug libfortran/26540] some gcc-4.1.0/libgfortran/intrinsics/signal.c warning: cast from/to pointer to/from integer of different size on x86-64
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-10 19:08 --- (In reply to comment #4) > Andrew, > The comment... > > These warnings are semi expected in that signal is expected not to work with > 64bit, this is due to g77 compatibility. > > ..is confusing. How is it confusing? G77 supported 64bit on most targets before gfotran was even released. Alpha-linux-gnu was a 64bit target where g77 was supported. x86_64-linux-gnu, ia64-linux-gnu and powerpc64-linux-gnu are others. It is not like 64bit support in GCC is new at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26540
[Bug target/29006] Incorrect zeroing of unaligned 64-bit fields on MIPS targets
-- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-10 19:08:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29006
[Bug fortran/27989] -fbounds-check should check for too small arrays on subroutine calls
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-09-10 19:23 --- Maybe this should not be done with -fbounds-check, but put into a different option. (NAG uses not -C=array but -C=call for this.) The reason is that some programs (e.g. Exciting.sf.net) passes an array(n-1) to a subroutine foo(n,b) with "real :: b(n)" but only accesses the first n-1 elements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27989
[Bug libfortran/26540] some gcc-4.1.0/libgfortran/intrinsics/signal.c warning: cast from/to pointer to/from integer of different size on x86-64
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2006-09-10 19:24 --- The confusing part was the words "signal is expected not to work with 64-bit" which left the impression that it only works with 32-bit currently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26540
[Bug target/29006] Incorrect zeroing of unaligned 64-bit fields on MIPS targets
--- Comment #2 from rsandifo at gcc dot gnu dot org 2006-09-10 19:28 --- Subject: Bug 29006 Author: rsandifo Date: Sun Sep 10 19:28:48 2006 New Revision: 116822 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116822 Log: gcc/ PR target/29006 * config/mips/mips-protos.h (mips_mem_fits_mode_p): Declare. * config/mips/mips.c (mips_expand_unaligned_store): Use the mode returned by mode_for_size, rather than the mode of src itself, to choose between 32-bit and 64-bit patterns. (mips_mem_fits_mode_p): New function. * config/mips/mips.md (mov_l, mov_r): Use it to check that the size of the source matches the size of the destination. (mov_l, mov_r): Likewise. gcc/testsuite/ PR target/29006 * gcc.c-torture/execute/pr29006.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr29006.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips-protos.h trunk/gcc/config/mips/mips.c trunk/gcc/config/mips/mips.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29006
[Bug target/29006] Incorrect zeroing of unaligned 64-bit fields on MIPS targets
--- Comment #3 from rsandifo at gcc dot gnu dot org 2006-09-10 19:31 --- Subject: Bug 29006 Author: rsandifo Date: Sun Sep 10 19:30:53 2006 New Revision: 116823 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116823 Log: gcc/ PR target/29006 * config/mips/mips-protos.h (mips_mem_fits_mode_p): Declare. * config/mips/mips.c (mips_expand_unaligned_store): Use the mode returned by mode_for_size, rather than the mode of src itself, to choose between 32-bit and 64-bit patterns. (mips_mem_fits_mode_p): New function. * config/mips/mips.md (mov_l, mov_r): Use it to check that the size of the source matches the size of the destination. (mov_l, mov_r): Likewise. gcc/testsuite/ PR target/29006 * gcc.c-torture/execute/pr29006.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/pr29006.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/mips/mips-protos.h branches/gcc-4_1-branch/gcc/config/mips/mips.c branches/gcc-4_1-branch/gcc/config/mips/mips.md branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29006
[Bug testsuite/29007] New: FAIL: gcc.dg/long-long-cst1.c execution test
Executing on host: /home/dave/gnu/gcc-4.2/objdir/gcc/xgcc -B/home/dave/gnu/gcc-4 .2/objdir/gcc/ /home/dave/gnu/gcc-4.2/gcc/gcc/testsuite/gcc.dg/long-long-cst1.c -fno-show-column -lm -o ./long-long-cst1.exe(timeout = 300) PASS: gcc.dg/long-long-cst1.c (test for excess errors) Setting LD_LIBRARY_PATH to :/home/dave/gnu/gcc-4.2/objdir/gcc::/home/dave/gnu/gc c-4.2/objdir/gcc:/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/.libs:/ho me/dave/gnu/gcc-4.2/objdir/hppa-linux/libmudflap/.libs:/home/dave/gnu/gcc-4.2/ob jdir/hppa-linux/libssp/.libs:/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libgomp/.l ibs:/home/dave/gnu/gcc-4.2/objdir/./gcc:/home/dave/gnu/gcc-4.2/objdir/./prev-gcc FAIL: gcc.dg/long-long-cst1.c execution test It looks like this test is missing an "exit (0);" or "return 0;" statement. -- Summary: FAIL: gcc.dg/long-long-cst1.c execution test Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29007
[Bug target/29006] Incorrect zeroing of unaligned 64-bit fields on MIPS targets
--- Comment #4 from rsandifo at gcc dot gnu dot org 2006-09-10 19:36 --- Subject: Bug 29006 Author: rsandifo Date: Sun Sep 10 19:36:20 2006 New Revision: 116824 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116824 Log: gcc/ PR target/29006 * config/mips/mips-protos.h (mips_mem_fits_mode_p): Declare. * config/mips/mips.c (mips_expand_unaligned_store): Use the mode returned by mode_for_size, rather than the mode of src itself, to choose between 32-bit and 64-bit patterns. (mips_mem_fits_mode_p): New function. * config/mips/mips.md (mov_l, mov_r): Use it to check that the size of the source matches the size of the destination. (mov_l, mov_r): Likewise. gcc/testsuite/ PR target/29006 * gcc.c-torture/execute/pr29006.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/pr29006.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/mips/mips-protos.h branches/gcc-4_0-branch/gcc/config/mips/mips.c branches/gcc-4_0-branch/gcc/config/mips/mips.md branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29006
[Bug target/29006] Incorrect zeroing of unaligned 64-bit fields on MIPS targets
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-09-10 19:38 --- Patch applied to trunk, 4.1 and 4.0. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29006
[Bug target/29006] Incorrect zeroing of unaligned 64-bit fields on MIPS targets
-- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.3 4.1.1 4.2.0 |4.0.3 4.1.1 Known to work|3.3 |3.3 4.0.4 4.1.2 4.2.0 Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29006
[Bug testsuite/29007] FAIL: gcc.dg/long-long-cst1.c execution test
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-10 19:40 --- I am going to take care of this, it is also missing a cast for 64bits reason. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-10 19:40:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29007
[Bug fortran/28923] Bad triplet interpretation in initialization
--- Comment #5 from pault at gcc dot gnu dot org 2006-09-10 19:43 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28923
[Bug fortran/28959] ICE on derived type with host association
--- Comment #6 from pault at gcc dot gnu dot org 2006-09-10 19:44 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28959
[Bug fortran/28947] Double MATMUL() uses wrong array elements
--- Comment #6 from pault at gcc dot gnu dot org 2006-09-10 19:44 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28947
[Bug middle-end/26983] [4.0/4.1/4.2 Regression] Missing label with builtin_setjmp/longjmp
--- Comment #12 from steven at gcc dot gnu dot org 2006-09-10 20:09 --- Subject: Bug 26983 Author: steven Date: Sun Sep 10 20:08:58 2006 New Revision: 116826 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116826 Log: PR middle-end/26983 gcc/ * builtins.c (expand_builtin_setjmp): Force next_lab to be preserved. testsuite/ * gcc.dg/pr26983.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr26983.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26983
[Bug middle-end/26983] [4.0/4.1 Regression] Missing label with builtin_setjmp/longjmp
--- Comment #13 from steven at gcc dot gnu dot org 2006-09-10 20:10 --- Fixed on the trunk. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] Missing |Missing label with |label with |builtin_setjmp/longjmp |builtin_setjmp/longjmp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26983
[Bug bootstrap/15212] [4.0/4.1/4.2 Regression] bootstrap fails on interix3
--- Comment #21 from mkoeppe at gmx dot de 2006-09-10 20:14 --- (In reply to comment #20) Update for gcc-4.2 == When installing GNU sed (I used 4.1.5) before configuring, the Makefile is created and building starts. "make bootstrap" nevertheless fails with: [...] Configuring stage 2 in ./intl configure: creating cache ./config.cache checking whether gmake sets $(MAKE)... yes checking for a BSD-compatible install... /bin/install -c checking whether NLS is requested... yes checking for msgfmt... /usr/local/bin/msgfmt checking for gmsgfmt... /usr/local/bin/msgfmt checking for xgettext... /usr/local/bin/xgettext checking for msgmerge... /usr/local/bin/msgmerge checking for i586-pc-interix3.5-gcc... /tmp/gcc-4.2/build/./prev-gcc/xgcc -B/tmp/gcc-4.2/build/./prev-gcc/ -B/usr/local/i586-pc-interix3.5/bin/ checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. gmake[2]: *** [configure-stage2-intl] Error 77 gmake[2]: Leaving directory `/tmp/gcc-4.2/build' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-4.2/build' gmake: *** [bootstrap] Error 2 (For gcc-4.0.3 the new sed doesn't make any difference.) Martin -- mkoeppe at gmx dot de changed: What|Removed |Added CC||mkoeppe at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
[Bug c++/29008] New: Fails to accept templated constructor
The code:
class foo {
public:
template
foo(int i) : j(i) {}
template
void bar(int i) { j = i; }
template
static
void baz(int i) {}
int j;
};
int main() {
foo::baz(3);
foo* p; p->bar(3);
new foo(3);
return 0;
}
gets you:
~/ootbc/chips$ g++ foo.cc
foo.cc: In function âint main()â:
foo.cc:8: error: âfooâ is not a template
foo.cc:8: error: no matching function for call to âfoo::foo(int)â
foo.cc:1: note: candidates are: foo::foo(const foo&)
The constructor was declared as a template, and declaring other functions works
OK.
I can believe that parsing a templated constructor for a templated class is
tough and so declaring templated constructors may be illegal. But if it is
illegal to have templated constructors then the error should be flagged at the
attempted declaration of one, rather than this peculiar message at the
invocation site. But it looks to me like the parser hit the "<" in "foo<", saw
that foo was not a template, and gave up before looking to see that the foo
constructor *was* a template.
--
Summary: Fails to accept templated constructor
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29008
[Bug c++/29008] Fails to accept templated constructor
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-10 20:41 --- I don't think this is valid code. ICC also rejects the code. It is valid for template constuctor but not specify which templated constuctor you will call. foo is not a template so that error message is correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29008
[Bug c++/29008] Fails to accept templated constructor
--- Comment #2 from igodard at pacbell dot net 2006-09-10 21:18 --- On further checking, you can have a templated constructor and invoke it - so long as it is fully resolved by the data arguments. You only get the diagnostic when the desired template has to be explicitly qualified. The compiler knows that qualification will be required because none of the function arguments depend on the template argument, so the template argument would have to be supplied explicitly and the declaration could be flagged at once (if this is in fact illegal) I think that the qualified invocation I reported is unambiguous, and certainly works for plain functions. But it's peculiar enough that both you and icc might have made the same mistake. Does the standard explicitly disallow this? If not then it should be accepted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29008
[Bug rtl-optimization/28636] [4.0/4.1 regression] Miscompiled loop
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-09-10 21:27 --- Subject: Bug 28636 Author: ebotcazou Date: Sun Sep 10 21:27:36 2006 New Revision: 116827 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116827 Log: PR rtl-optimization/28636 * combine.c (force_to_mode): Test for side-effects before substituting by zero. (simplify_shift_const): Likewise for zero or other constants. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20060910-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28636
[Bug rtl-optimization/28636] [4.0/4.1 regression] Miscompiled loop
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-10 21:28 --- Subject: Bug 28636 Author: ebotcazou Date: Sun Sep 10 21:28:03 2006 New Revision: 116828 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116828 Log: PR rtl-optimization/28636 * combine.c (force_to_mode): Test for side-effects before substituting by zero. (simplify_shift_const): Likewise for zero or other constants. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/20060910-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/combine.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28636
[Bug rtl-optimization/28636] [4.0/4.1 regression] Miscompiled loop
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-09-10 21:28 --- Subject: Bug 28636 Author: ebotcazou Date: Sun Sep 10 21:28:39 2006 New Revision: 116829 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116829 Log: PR rtl-optimization/28636 * combine.c (force_to_mode): Test for side-effects before substituting by zero. (simplify_shift_const): Likewise for zero or other constants. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/20060910-1.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/combine.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28636
[Bug rtl-optimization/28636] [4.0/4.1 regression] Miscompiled loop
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2006-09-10 21:34 --- Fixed everywhere. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||09/msg00383.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28636
[Bug c/29009] New: ice in kernel build
I just tried to compile Linux kernel 2.6.17.13 with the new GNU C compiler version 4.2 snapshot 20060909. The compiler said /home/dcb/gnu/42-20060909/results/bin/gcc -g -O3 -Wall -Wp,-MD,arch/x86_64/kernel/.asm-offsets.s.d -nostdinc -isystem /home/dcb/gnu/42-20060909/results/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -fno-omit-frame-pointer -fno-optimize-sibling-calls -fasynchronous-unwind-tables -g -march=k8 -m64 -mno-red-zone -mcmodel=kernel -pipe -ffunction-sections -fno-reorder-blocks -Wno-sign-compare -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wdeclaration-after-statement -Wno-pointer-sign-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(asm_offsets)" -D"KBUILD_MODNAME=KBUILD_STR(asm_offsets)" -fverbose-asm -S -o arch/x86_64/kernel/asm-offsets.s arch/x86_64/kernel/asm-offsets.c arch/x86_64/kernel/asm-offsets.c: In function "main": arch/x86_64/kernel/asm-offsets.c:72: internal compiler error: in ix86_compute_frame_layout, at config/i386/i386.c:5108 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Preprocessed source code attached. Flags -Os -mno-sse required. -- Summary: ice in kernel build Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: i686-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29009
[Bug c++/27177] [4.0/4.1/4.2 Regression] ICE in build_simple_base_path, at cp/class.c:474
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
[Bug c/29009] ice in kernel build
--- Comment #1 from dcb314 at hotmail dot com 2006-09-10 21:56 --- Created an attachment (id=12217) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12217&action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29009
[Bug target/29009] ice in kernel build
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-10 21:59 --- gcc_assert (preferred_alignment <= PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29009
[Bug target/29009] [4.2 Regression] ice in kernel build
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-10 22:03 --- Caused by the patch which fixed PR 13685. Jason removed the check for TARGET_64BIT which was incorrect. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Keywords||ice-on-valid-code Summary|ice in kernel build |[4.2 Regression] ice in ||kernel build Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29009
[Bug c++/27177] [4.0/4.1/4.2 Regression] ICE in build_simple_base_path, at cp/class.c:474
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-09-10 22:04
---
I am not convinced that the code in Comment #8 is valid.
Although the operand of sizeof is not in fact evaluated, it seems odd to permit
an operand which cannot, even in principle, be evaluated. This is not even a
case in which evaluating the operand would lead to undefined behavior; there is
simply no way to evaluate the operand at all. If there is an implicit
conversion from B* to Z* at this point, then we must know how to performn the
conversion, but we cannot, since B is not complete.
Are you arguing that in:
struct B {};
struct D : public B {
static const int i = sizeof((B*)(D*)0);
};
the conversion from D* to B* is a static_cast?
Has anyone asked about this case on the core reflector?
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
[Bug c++/28985] [4.0/4.1/4.2 Regression] class member access using a qualified-id fails to check for match of classes
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-09-10 22:09 --- The rules in the standard regarding destructor lookup, what constitues the same name, etc., are not well-specified. The last time I investigated this, the EDG front end used rules which did not seem to match the standard, but, IIRC, John Spicer argued that was a bug in the standard. In any case, this case is certainly invalid, but it may also be dangerous to try to fix it. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28985
[Bug c++/28988] [4.0/4.1/4.2 Regression] g++ does not check first type name in pseudo-destructor-name
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28988
[Bug c++/28989] [4.0/4.1/4.2 Regression] post-increment of bool variable accepted as lvalue
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28989
[Bug middle-end/28463] [4.0/4.1/4.2 Regression] Using -fdump-tree-optimized causes a huge compile time memory regression
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-10 22:26 --- (In reply to comment #1) > Yup. And a regression too because previous GCCs could dump without sending > your > machine to swap space land. Not really, anyways this is fixed now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28463
[Bug bootstrap/28949] configure-target-libiberty: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-10 22:26 --- As I mentioned already this is not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.2.0 | Known to work|4.1.1 | Summary|[4.2 regression] configure- |configure-target-libiberty: |target-libiberty: Link tests|Link tests are not allowed |are not allowed after |after GCC_NO_EXECUTABLES |GCC_NO_EXECUTABLES | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
