[Bug rtl-optimization/24460] [4.1 regression] Profiled bootstrap broken
--- Comment #9 from cvs-commit at gcc dot gnu dot org 2005-10-26 07:03 --- Subject: Bug 24460 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-26 07:03:32 Modified files: gcc: ChangeLog bb-reorder.c dwarf2out.c output.h varasm.c Log message: PR rtl-optimization/24460 * dwarf2out.c (have_switched_text_sections): New boolean variable. (dwarf2out_switch_text_section): Set it to true instead of incrementing separate_line_info_table_in_use. (output_loc_list): Additionally test have_switched_text_sections. (output_ranges): Likewise. (dwarf2out_finish): Likewise. * varasm.c (assemble_start_function): Do not call insert_section_boundary_note. (assemble_end_function): If flag_reorder_blocks_and_partition, switch to the function's section before emitting the .size directive. * bb-reorder.c (insert_section_boundary_note): Staticify. (rest_of_handle_reorder_blocks): Call insert_section_boundary_note. * output.h (insert_section_boundary_note): Delete. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10214&r2=2.10215 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/bb-reorder.c.diff?cvsroot=gcc&r1=1.115&r2=1.116 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gcc&r1=1.615&r2=1.616 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/output.h.diff?cvsroot=gcc&r1=1.161&r2=1.162 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&r1=1.534&r2=1.535 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24460
[Bug rtl-optimization/24460] [4.1 regression] Profiled bootstrap broken
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2005-10-26 07:10 --- See http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01409.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24460
[Bug fortran/24158] ICE in f951 with nested, recursive derived types
--- Comment #6 from pault at gcc dot gnu dot org 2005-10-26 07:57 --- Fixed on mainline and 4.03 Farewell cvs! -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24158
[Bug fortran/24534] New: gfortran: regression w/ PUBLIC derived types with private components
Hi, the following valid code snippet recently stopped to compile cleanly: module gfcbug28 ! A publicly visible derived type with private components type, public :: my_t private type(offset_t) :: offset end type my_t ! Everything else is private... private type offset_t integer :: i end type offset_t end module gfcbug28 I get: In file gfcbug28.f90:4 type, public :: my_t 1 Error: The component 'offset' is a PRIVATE type and cannot be a component of 'my_t', which is PUBLIC at (1) This is clearly nonsense. Although the type "my_t" is PUBLIC, its components are not. Cheers, -ha -- Summary: gfortran: regression w/ PUBLIC derived types with private components Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24534
[Bug c++/24535] New: ICE
-- Summary: ICE Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24535
[Bug c++/24535] ICE
--- Comment #1 from igodard at pacbell dot net 2005-10-26 08:17 --- Created an attachment (id=10059) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10059&action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24535
[Bug c++/24535] ICE
--- Comment #2 from igodard at pacbell dot net 2005-10-26 08:20 --- Created an attachment (id=10060) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10060&action=view) source code (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24535
[Bug libgcj/23763] Runtime.getRuntime().exec() signalling
--- Comment #6 from aeby at graeff dot com 2005-10-26 08:48 --- I have just tested against 4.0.2 and the bug is still there (no surprise, of course). -- aeby at graeff dot com changed: What|Removed |Added Known to fail|4.0.0 4.0.1 |4.0.0 4.0.1 4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763
[Bug libgcj/23763] Runtime.getRuntime().exec() signalling
--- Comment #7 from tromey at gcc dot gnu dot org 2005-10-26 09:01 --- Sorry for the delay on this. The patch looks reasonable enough to me. It needs a small amount of reformatting and a ChangeLog entry. Also I think the call to signal() is not needed, a custom handler is reset to the default on exec. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-26 09:01:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763
[Bug c++/24512] [gomp] Bogus error message about redeclared variables
--- Comment #1 from cvs-commit at gcc dot gnu dot org 2005-10-26 09:20 --- Subject: Bug 24512 CVSROOT:/cvs/gcc Module name:gcc Branch: gomp-20050608-branch Changes by: [EMAIL PROTECTED] 2005-10-26 09:20:37 Modified files: gcc: ChangeLog.gomp c-common.h c-omp.c c-parser.c gcc/cp : ChangeLog.gomp gcc/testsuite : ChangeLog.gomp gcc/cp : semantics.c parser.c cp-tree.h pt.c Added files: gcc/testsuite/g++.dg/gomp: for-15.C Log message: PR c++/24512 * c-common.h (c_finish_omp_for): Add PRE_BODY argument. * c-omp.c (c_finish_omp_for): Likewise. Set OMP_FOR_PRE_BODY to that argument. * c-parser.c (c_parser_omp_for_loop): Adjust c_finish_omp_for caller. cp/ * cp-tree.h (finish_omp_for): Add PRE_BODY argument. * semantics.c (finish_omp_for): Likewise. Set OMP_FOR_PRE_BODY to PRE_BODY if deferring, add it into the current statement list if not processing template decl or pass it to c_finish_omp_for. * parser.c (cp_parser_omp_for_loop): Expand optional DECL_EXPRs into PRE_BODY statement list. Pass it to finish_omp_for. * pt.c (tsubst_expr) : tsubst_expr also OMP_FOR_PRE_BODY into PRE_BODY stmt list, pass it to finish_omp_for. Put all the statements into sk_omp scope. testsuite/ * g++.dg/gomp/for-15.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.gomp.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.1.6.107&r2=1.1.6.108 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.h.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.294.4.15&r2=1.294.4.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-omp.c.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.1.2.15&r2=1.1.2.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-parser.c.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=2.17.4.38&r2=2.17.4.39 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.gomp.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.1.8.25&r2=1.1.8.26 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.gomp.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.1.2.47&r2=1.1.2.48 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.475.4.21&r2=1.475.4.22 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.340.4.22&r2=1.340.4.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.1144.4.18&r2=1.1144.4.19 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=1.1005.4.11&r2=1.1005.4.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/gomp/for-15.C.diff?cvsroot=gcc&only_with_tag=gomp-20050608-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24512
[Bug target/24536] New: [4.1 Regression] Register allocation to mmx asms broken
We fail to allocate an mmx register to class 'X' since the last couple of weeks
(20051015 worked). Testcase:
typedef union {
long long q;
unsigned long long uq;
} __attribute__ ((aligned (8))) mmx_t;
static mmx_t mmx_0x8080s = (mmx_t) 0x8080808080808080LL;
void dv_mb411_right_YUY2_mmx(void)
{
short *cr_frame;
int row;
for (row = 0; row < 8; row++)
{
__asm__ __volatile__ ("movq" " %0, %%" "mm1" : : "X" (*cr_frame));
__asm__ __volatile__ ("paddb" " %0, %%" "mm3" : : "X" (mmx_0x8080s));
}
}
where we produce with -O2:
.L2:
#APP
movq %bx, %mm1
paddb %edx, %mm3
#NO_APP
which of course makes the assembler barf.
--
Summary: [4.1 Regression] Register allocation to mmx asms broken
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: critical
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: i686-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24536
[Bug target/24536] Register allocation to mmx asms broken
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-10-26 10:06 --- Note this makes libdv fail to compile. Oh, and it did not work with 20051015 - every compiler I tried fails on the testcase. Hmm, which maybe makes it invalid? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Summary|[4.1 Regression] Register |Register allocation to mmx |allocation to mmx asms |asms broken |broken | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24536
[Bug libstdc++/24537] New: Non-uglified names inside namespace __gnu_cxx
This is to keep track of this issue: http://gcc.gnu.org/ml/libstdc++/2005-10/msg00077.html In short, there is a small issue, with __gnu_cxx::char_traits (actually, we should do an audit), and a larger issue with the legacy HP/SGI free functions included via headers like , ... -- Summary: Non-uglified names inside namespace __gnu_cxx Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24537
[Bug middle-end/20937] BLK ptr's losing original ptr's static-constant readonly attribute.
--- Comment #8 from schlie at comcast dot net 2005-10-26 10:33 ---
Subject: Re: BLK ptr's losing original ptr's
static-constant readonly attribute.
> --- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-25 19:22
> (In reply to comment #6)
>> - For some reason, GCC is casting "char" to "int" prior to returning their
>> value as a "char", which
>>although works, is a fairly gross mis-optimization? (which should also
>> likely be considred a bug).
>
> That is an ABI issue. Also it is most likely not able to change as some
> people still use K&R C where
> f()
> {
> return 1;
> }
>
> Is still valid.
- one would think that abi issues such as these should be addressed
within the target's .md file/port; not within the core compiler itself.
- nor should: char f(){ return 1; } ever need to cast 1 to an int, as char
is a perfectly legitimate integer size.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20937
[Bug libstdc++/24538] New: Build not working as expected --enable-shared
Mingw32 Platforms.(might be all win32 platforms) --enable-shared=libstdc++ You kinda expect to get a dll. Development version and Production Versions would be great. Ie Development version linked to dll Production Version using static. If you don't have the time to fix it point me to the resources and I will try to create the patch myself. Number one I don't normal work with autoconf systems so I would feel better passing it up to a more experenced person. -- Summary: Build not working as expected --enable-shared Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oiaohm at myrealbox dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24538
[Bug target/24536] [4.1 Regression] Register allocation to mmx asms broken
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-10-26 10:54 --- I just verified that we build the unreduced testcase with gcc 4.0. So it might be good/bad luck that it worked. Practically it still is a regression from 4.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|Register allocation to mmx |[4.1 Regression] Register |asms broken |allocation to mmx asms ||broken http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24536
[Bug target/24536] [4.1 Regression] Register allocation to mmx asms broken
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-10-26 10:54 --- Created an attachment (id=10061) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10061&action=view) unreduced testcase unreduced testcase for verification -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24536
[Bug target/24536] [4.1 Regression] Register allocation to mmx asms broken
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-10-26 11:01 ---
Reduced testcase that works with 4.0 and fails with 4.1
typedef union {
long long q;
unsigned long long uq;
} __attribute__ ((aligned (8))) mmx_t;
static mmx_t mmx_0x8080s = (mmx_t) 0x8080808080808080LL;
void dv_mb411_right_YUY2_mmx(void)
{
unsigned char *pyuv;
int row;
for (row = 0; row < 8; row++)
{
__asm__ __volatile__ ("paddb" " %0, %%" "mm2" : : "X" (mmx_0x8080s));
__asm__ __volatile__ ("movq" " %%" "mm2" ", %0" : "=X" (pyuv [8]) : );
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24536
[Bug fortran/15586] gfortran should support i18n in its compiler messages
--- Comment #11 from cvs-commit at gcc dot gnu dot org 2005-10-26 11:02 --- Subject: Bug 15586 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-26 11:02:00 Modified files: gcc/fortran: ChangeLog resolve.c Log message: PR fortran/15586 * resolve.c (resolve_symbol): Remove the use of whynot, so that error messages are not built from pieces. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.601&r2=1.602 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.65&r2=1.66 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15586
[Bug fortran/15586] gfortran should support i18n in its compiler messages
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2005-10-26 11:05 --- Fixed, now no message is built from pieces anymore. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2005- | |10/msg01407.html| Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15586
[Bug c++/24512] [gomp] Bogus error message about redeclared variables
--- Comment #2 from reichelt at gcc dot gnu dot org 2005-10-26 11:05 --- Fixed on the gomp branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24512
[Bug target/24536] [4.1 Regression] Register allocation to mmx asms broken
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-10-26 11:28 --- Ok, libdv is really crap. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24536
[Bug preprocessor/23779] '-C' option produces wrong output
--- Comment #3 from segher at kernel dot crashing dot org 2005-10-26 11:44 --- The (first) carriage return issue is a separate bug, though. Please reopen? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23779
[Bug target/24536] [4.1 Regression] Register allocation to mmx asms broken
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-26 12:18 --- X means any register by the way (this is why this is invalid). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24536
[Bug c++/24535] ICE
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-10-26 12:19 --- Fixed in CVS. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24535
[Bug target/24536] [4.1 Regression] Register allocation to mmx asms broken
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-10-26 12:20 --- Yeah - noticed that after taking X for x ... which wouldn't have made sense, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24536
[Bug target/24529] arm_print_operand, at config/arm/arm.c:9869
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-10-26 12:25 --- This is a duplicate *** This bug has been marked as a duplicate of 22331 *** -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24529
[Bug target/22331] internal compiler error: in arm_print_operand, at config/arm/arm.c:9869
--- Comment #4 from rearnsha at gcc dot gnu dot org 2005-10-26 12:25 --- *** Bug 24529 has been marked as a duplicate of this bug. *** -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||brian at bulkowski dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22331
[Bug libstdc++/24538] Build not working as expected --enable-shared
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-26 12:31 --- IIRC there were recent patches to fix this BUT I don't know the state of them. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||win32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24538
[Bug target/24528] [ARM EB] strcpy() of small string constant produces wrong instructions
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-10-26 12:33 --- If you can't upgrade to gcc-3.4, see the patch link in the bug this is a duplicate of *** This bug has been marked as a duplicate of 22528 *** -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24528
[Bug target/22528] Optimized ARM 'unsigned short's assignments are incorrect for big-endian ARMv3 targets
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-10-26 12:33 --- *** Bug 24528 has been marked as a duplicate of this bug. *** -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||djohnson+gcc at sw dot ||starentnetworks dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22528
[Bug libstdc++/24537] Non-uglified names inside namespace __gnu_cxx
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-26 12:34 --- Seems like to me, this is what namespaces are for anyways? and non-uglified names are correct, maybe it needs to be a different namespace like __gnu_cxx::__implemenation instead which seems like the more correct thing to do than uglify names. I think this is what Boost does too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24537
[Bug target/24536] [4.1 Regression] Register allocation to mmx asms broken
--- Comment #8 from pluto at agmk dot net 2005-10-26 12:36 --- (In reply to comment #7) > Yeah - noticed that after taking X for x ... which wouldn't have made sense, > too. > I've detected an ICE-on-invalid code with "y" constraint (MMX register) pr24536.c:16: error: impossible register constraint in ‘asm’ pr24536.c:19: internal compiler error: in ix86_secondary_memory_needed, at config/i386/i386.c:15827 -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24536
[Bug libstdc++/24537] Non-uglified names inside namespace __gnu_cxx
--- Comment #2 from pcarlini at suse dot de 2005-10-26 12:37 --- (In reply to comment #1) > Seems like to me, this is what namespaces are for anyways? and non-uglified > names are correct, maybe it needs to be a different namespace like > __gnu_cxx::__implemenation instead which seems like the more correct thing to > do than uglify names. I think this is what Boost does too. Indeed, the idea is using namespaces. But seems much more clean to me using separate namespaces, not nested ones, for our problem: __gnu_cxx for new extensions and __gnu_legacy for legacy extensions. The implementation proper bits are instead already inside __gnu_internal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24537
[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec
--- Comment #12 from rguenth at gcc dot gnu dot org 2005-10-26 12:54 --- reload -> Micha, can you try to track this down? It makes xvid ICE on beta-ppc. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||matz at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
[Bug tree-optimization/24483] [4.1 Regression] ICE in ivopts
--- Comment #3 from rakdver at gcc dot gnu dot org 2005-10-26 13:02 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01527.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24483
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #7 from micis at gmx dot de 2005-10-26 14:17 --- With the snapshot gcc-4.1-20051022 I get the following additional errors when I use --enable-checking=fold and run make check gcc.c-torture/compile/20021108-1.c gcc.c-torture/compile/920501-7.c gcc.c-torture/compile/labels-1.c gcc.c-torture/compile/labels-2.c gcc.c-torture/compile/labels-3.c gcc.dg/20021029-1.c gcc.dg/pr16973.c all fail with the message: "internal compiler error: fold check: original tree changed by fold" Michael -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug c/24539] New: inconsistent handling of null-valued language hooks in GCC
Also posted to the GCC mailing list:
http://gcc.gnu.org/ml/gcc/2005-10/msg00932.html
http://gcc.gnu.org/ml/gcc/2005-10/msg00938.html
While working with GCC's language hooks, we found that
certain places in GCC test for a null value of
lang_hooks.callgraph.expand_function, but
cgraph_expand_function() calls the hook directly:
In cgraphunit.c:
/* Expand function specified by NODE. */
static void
cgraph_expand_function (struct cgraph_node *node)
{
tree decl = node->decl;
/* We ought to not compile any inline clones. */
gcc_assert (!node->global.inlined_to);
if (flag_unit_at_a_time)
announce_function (decl);
cgraph_lower_function (node);
/* Generate RTL for the body of DECL. */
lang_hooks.callgraph.expand_function (decl);
In toplev.c:
/* Disable unit-at-a-time mode for frontends not supporting callgraph
interface. */
if (flag_unit_at_a_time && ! lang_hooks.callgraph.expand_function)
flag_unit_at_a_time = 0;
In function.c:
/* Possibly warn about unused parameters.
When frontend does unit-at-a-time, the warning is already
issued at finalization time. */
if (warn_unused_parameter
&& !lang_hooks.callgraph.expand_function)
do_warn_unused_parameter (current_function_decl);
We tried setting lang_hooks.callgraph.expand_function to NULL:
/* For now, disable unit-at-a-time by setting expand_function to NULL */
#undef LANG_HOOKS_CALLGRAPH_EXPAND_FUNCTION
#define LANG_HOOKS_CALLGRAPH_EXPAND_FUNCTION NULL
which has the desired effect of disabling unit-at-a-time, but
runs aground in cgraph_expand_function() with a segfault,
when it attempts to call lang_hooks.callgraph.expand_function().
It seems that GCC is handling lang_hooks.callgraph.expand_function
in an inconsistent fashion. Is a null value for expand_function
meaningful? If it is, then what is the fix for cgraph_expand_function()?
In a follow-up note on the GCC list, Dueway Qi notes:
I have found another similar case.
lang_hooks.callgraph.analyze_expr in gcc/gcc/cgraphunit.c
490 if (lang_hooks.callgraph.analyze_expr)
491 return lang_hooks.callgraph.analyze_expr (tp,
walk_subtrees,
492 data);
but in another part of this file
517 if ((unsigned int) TREE_CODE (t) >= LAST_AND_UNUSED_TREE_CODE)
518 return lang_hooks.callgraph.analyze_expr (tp,
walk_subtrees, data);
--
Summary: inconsistent handling of null-valued language hooks in
GCC
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24539
[Bug c/24540] New: inconsistent handling of null-valued language hooks in GCC
Also posted to the GCC mailing list:
http://gcc.gnu.org/ml/gcc/2005-10/msg00932.html
http://gcc.gnu.org/ml/gcc/2005-10/msg00938.html
While working with GCC's language hooks, we found that
certain places in GCC test for a null value of
lang_hooks.callgraph.expand_function, but
cgraph_expand_function() calls the hook directly:
In cgraphunit.c:
/* Expand function specified by NODE. */
static void
cgraph_expand_function (struct cgraph_node *node)
{
tree decl = node->decl;
/* We ought to not compile any inline clones. */
gcc_assert (!node->global.inlined_to);
if (flag_unit_at_a_time)
announce_function (decl);
cgraph_lower_function (node);
/* Generate RTL for the body of DECL. */
lang_hooks.callgraph.expand_function (decl);
In toplev.c:
/* Disable unit-at-a-time mode for frontends not supporting callgraph
interface. */
if (flag_unit_at_a_time && ! lang_hooks.callgraph.expand_function)
flag_unit_at_a_time = 0;
In function.c:
/* Possibly warn about unused parameters.
When frontend does unit-at-a-time, the warning is already
issued at finalization time. */
if (warn_unused_parameter
&& !lang_hooks.callgraph.expand_function)
do_warn_unused_parameter (current_function_decl);
We tried setting lang_hooks.callgraph.expand_function to NULL:
/* For now, disable unit-at-a-time by setting expand_function to NULL */
#undef LANG_HOOKS_CALLGRAPH_EXPAND_FUNCTION
#define LANG_HOOKS_CALLGRAPH_EXPAND_FUNCTION NULL
which has the desired effect of disabling unit-at-a-time, but
runs aground in cgraph_expand_function() with a segfault,
when it attempts to call lang_hooks.callgraph.expand_function().
It seems that GCC is handling lang_hooks.callgraph.expand_function
in an inconsistent fashion. Is a null value for expand_function
meaningful? If it is, then what is the fix for cgraph_expand_function()?
In a follow-up note on the GCC list, Dueway Qi notes:
I have found another similar case.
lang_hooks.callgraph.analyze_expr in gcc/gcc/cgraphunit.c
490 if (lang_hooks.callgraph.analyze_expr)
491 return lang_hooks.callgraph.analyze_expr (tp,
walk_subtrees,
492 data);
but in another part of this file
517 if ((unsigned int) TREE_CODE (t) >= LAST_AND_UNUSED_TREE_CODE)
518 return lang_hooks.callgraph.analyze_expr (tp,
walk_subtrees, data);
--
Summary: inconsistent handling of null-valued language hooks in
GCC
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24540
[Bug c/24540] inconsistent handling of null-valued language hooks in GCC
--- Comment #1 from gary at intrepid dot com 2005-10-26 14:39 --- *** This bug has been marked as a duplicate of 24539 *** -- gary at intrepid dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24540
[Bug c/24539] inconsistent handling of null-valued language hooks in GCC
--- Comment #1 from gary at intrepid dot com 2005-10-26 14:39 --- *** Bug 24540 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24539
[Bug libfortran/24541] New: _gfortran_ioparm changes size
When I run a FORTRAN program, compiled with gcc 4.0, against libgfortran in gcc 4.1, I got a.out: Symbol `_gfortran_ioparm' has different size in shared object, consider re-linking [EMAIL PROTECTED] 0004]$ readelf -s /usr/gcc-4.1/lib/libgfortran.so| grep _gfortran_ioparm 636: 000688e0 252 OBJECT GLOBAL DEFAULT 23 _gfortran_ioparm 1617: 000688e0 252 OBJECT GLOBAL DEFAULT 23 _gfortran_ioparm [EMAIL PROTECTED] 0004]$ readelf -s /usr/gcc-4.0/lib/libgfortran.so| grep _gfortran_ioparm 518: 00056740 240 OBJECT GLOBAL DEFAULT 23 _gfortran_ioparm 1005: 00056740 240 OBJECT GLOBAL DEFAULT 23 _gfortran_ioparm It is very bad since due to copy relocation, _gfortran_ioparm will only have 240 bytes at run-time. Please consider using symbol versioning or a different soname for libgfortran. -- Summary: _gfortran_ioparm changes size Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon 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=24541
[Bug target/24536] [4.1 Regression] Register allocation to mmx asms broken
--- Comment #9 from uros at kss-loka dot si 2005-10-26 14:41 ---
(In reply to comment #8)
> I've detected an ICE-on-invalid code with "y" constraint (MMX register)
You should use memory input/output:
__asm__ __volatile__ ("paddb" " %0, %%" "mm2"::"m" (mmx_0x8080s));
__asm__ __volatile__ ("movq" " %%" "mm2" ", %0":"=m" (pyuv[8]):);
to produce:
#APP
paddb mmx_0x8080s, %mm2
movq %mm2, 8(%eax)
#NO_APP
>
> pr24536.c:16: error: impossible register constraint in ‘asm’
> pr24536.c:19: internal compiler error: in ix86_secondary_memory_needed,
> at config/i386/i386.c:15827
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24536
[Bug c/24542] New: integer overflow should be warned on assignment to wider variable
The following code is ISO and ANSI standard compliant:
unsigned x1, x2;
unsigned long long y1;
... /* here we assign to x1 and x2 */
y1 = x1 * x2; /* no castings -- silent overflow may occur on assignment */
...
{
unsigned long long y2 = x1 * x2; /* no castings -- silent overflow may
occur on initialization */
...
}
(Instead of multiplication, addition or left shift shold be dealt with, too.)
When the binary operation result is assigned to lvalue of the same width, it's
OK not to warn about probable overflow. But in these cases, "do what I mean" is
obvious.
--
Summary: integer overflow should be warned on assignment to wider
variable
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexey at hyperroll dot com
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=24542
[Bug libfortran/24541] libgfortran.so in 4.1 is incompatible with 4.0
--- Comment #1 from hjl at lucon dot org 2005-10-26 15:01 --- I built SPEC CPU 2K with gcc 4.0 and ran with libgfortran.so in gcc 4.1. I got Specinvoke: /export/spec/src/2000/spec/bin/specinvoke -E -d /export/spec/src/2000/spec/benchspec/CFP2000/172.mgrid/run/0002 -c 1 -e compare.err -o compare.out -f compare.cmd *** Miscompare of mgrid.out, see /export/spec/src/2000/spec/benchspec/CFP2000/172.mgrid/run/0002/mgrid.out.mis 0447: 0.724205E-09 0.722967E-09 ^ 0448: 0.724205E-09 0.722967E-09 ^ 0449: 0.724366E-09 0.723163E-09 ^ 0511: 0.132651E-09 0.131288E-09 ^ 0512: 0.132651E-09 0.131288E-09 ^ 0513: 0.966122E-10 0.949407E-10 ^ 0514: 0.966122E-10 0.949407E-10 ^ 0515: 0.102259E-09 0.100198E-09 ^ 0516: 0.102259E-09 0.100198E-09 ^ 0517: 0.101682E-09 0.992215E-10 ^ 0518: 0.101682E-09 0.992215E-10 ^ Change to libgfortran.so in gcc 4.0 fixed the problem. I have 2 questions: 1. Is output of FORTRAN in gcc 4.1 binary compatible with gcc 4.0? 2. Should libgfortran.so in gcc 4.1 be backward compatible with libgfortran.so in gcc 4.0? -- hjl at lucon dot org changed: What|Removed |Added Summary|_gfortran_ioparm changes|libgfortran.so in 4.1 is |size|incompatible with 4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24541
[Bug c/24542] integer overflow should be warned on assignment to wider variable
--- Comment #1 from alexey at hyperroll dot com 2005-10-26 15:01 --- I'm not familiar with the parse tree, so I could do only a partial patch (assignment, not initialization). The example file, original and patched source files archived and attached. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542
[Bug c/24542] integer overflow should be warned on assignment to wider variable
--- Comment #2 from alexey at hyperroll dot com 2005-10-26 15:03 --- Created an attachment (id=10062) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10062&action=view) example of code to warn, proposed partial patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542
[Bug swing/17360] JScrollPane has incorrect size when JList with specified size is added to it
--- Comment #4 from abalkiss at redhat dot com 2005-10-26 15:23 ---
This appears to be a problem with JScrollPane.getPreferredSize(), as the
FlowLayout sets the size of the JScrollPane to its preferredSize, and then this
is a bound for the layout in ScrollPaneLayout which then sets an inappropriate
size for the JViewport.
The simple testcase below shows that JScrollPane is returning an inappropriate
value for getPreferredSize.
***TESTCASE***
import java.awt.*;
import javax.swing.*;
class Test2
{
public static void main(String[] args)
{
JFrame f = new JFrame();
String[] items =
{
"Item1", "Item2", "Item3", "Item4", "Item5", "Item6",
"Item7", "Item8", "Item9", "Item10", "Item11"
};
JList list = new JList(items);
list.setPreferredSize(new Dimension(150, 150));
f.setLayout(new FlowLayout());
JScrollPane scroller = new JScrollPane(list);
System.out.println ("scroll pane pref size: "+scroller.getPreferredSize());
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17360
[Bug c++/24543] New: g++ crashes
Hi, g++ crashes with the source attached. I called g++ as: > g++ bug.i sql_pars.c:117154: interner Compiler-Fehler: Speicherzugriffsfehler my translation of the german error message: internal compiler error, memory access violation g++ -v results: Es werden eingebaute Spezifikationen verwendet. Ziel: i586-suse-linux Konfiguriert mit: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,f95,java,ada --disable-checking --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk --disable-libjava-multilib --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --without-system-libunwind --host=i586-suse-linux Thread-Modell: posix gcc-Version 4.0.2 20050901 (prerelease) (SUSE Linux) -- Summary: g++ crashes Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: juergen dot vollmer at informatik-vollmer dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24543
[Bug c++/24543] g++ crashes
--- Comment #1 from juergen dot vollmer at informatik-vollmer dot de 2005-10-26 15:53 --- Created an attachment (id=10063) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10063&action=view) the gzip'ed (prepreocessed) source causing the crash This source cuases the crash. Call it as g++ bug.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24543
[Bug middle-end/24539] inconsistent handling of null-valued language hooks in GCC
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-26 15:54 --- I think analyze_expr should be removed as by the time we get there, we are always in gimple. As for expand_function, we really should have a default one now as almost no language does not support unit at a time. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24539
[Bug libfortran/24541] libgfortran.so in 4.1 is incompatible with 4.0
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-26 15:56 --- This is actually the issue is that 4.0.x's gfortran is experimental and really should not be thought about be used in normal use, even to compile and then link with a newer version. This has been discussed before. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24541
[Bug c/24542] potential integer overflow should be warned on assignment to wider variable
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-26 15:59 --- You should be patching the mainline as the C parser has changed to a non bison based parser. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542
[Bug c/24542] potential integer overflow should be warned on assignment to wider variable
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-26 16:00 --- Please also make the warning conditional based on an option and make the option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542
[Bug c++/24543] g++ crashes
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24543
[Bug libfortran/24541] libgfortran.so in 4.1 is incompatible with 4.0
--- Comment #3 from hjl at lucon dot org 2005-10-26 16:06 --- Then rename _gfortran_ioparm to something like _gfortran_version_4.1_ioparm and change soname of libgfortran from libgfortran.so.0 to something like libgfortran.so.0.1. When libgfortran's ABI is changed, we should update its soname and try to prevent mixing inputs with different ABIs. -- hjl at lucon dot org changed: What|Removed |Added Severity|minor |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24541
[Bug middle-end/24539] inconsistent handling of null-valued language hooks in GCC
--- Comment #3 from gary at intrepid dot com 2005-10-26 16:07 --- All/most GCC-supplied dialects may support unit-at-a-time, however, the dialect we're working on (UPC) does not at present support unit-at-a-time. For now, we're de-asserting flag_unit_at_a_time in the language specific post_options routine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24539
[Bug libfortran/24541] libgfortran.so in 4.1 is incompatible with 4.0
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-26 16:07 --- This is still minor as the ABI was expected to change and really you should not be doing this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24541
[Bug middle-end/24539] inconsistent handling of null-valued language hooks in GCC
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-26 16:09 --- (In reply to comment #3) > For now, we're de-asserting flag_unit_at_a_time in the language > specific post_options routine. You should note that non unit-at-a-time will be removed in the future so you may as well just do unit at a time to start with. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24539
[Bug libfortran/24541] libgfortran.so in 4.1 is incompatible with 4.0
--- Comment #5 from hjl at lucon dot org 2005-10-26 16:19 --- So what? ABI of glibc changes. ABI of libstdc++ changes. When the ABI changes, we should manage it in such a way that it won't cause problems for existing executables and shared libraries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24541
[Bug c++/24543] [4.0/4.1 Regression] g++ crashes
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-26 16:20 --- Fixed in at least 4.0.3. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|g++ crashes |[4.0/4.1 Regression] g++ ||crashes Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24543
[Bug c++/24543] [4.0/4.1 Regression] g++ crashes
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-26 16:29 --- Actually this was fixed in the 4.0.2 release. This is a dup of bug 21135. *** This bug has been marked as a duplicate of 21135 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work|3.4.0 4.0.3 4.1.0 |3.4.0 4.0.3 4.1.0 4.0.2 Resolution||DUPLICATE Target Milestone|4.0.3 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24543
[Bug c++/21135] [4.0 Regression] &a[-2] ICE at the top level
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-10-26 16:29 --- *** Bug 24543 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||juergen dot vollmer at ||informatik-vollmer dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21135
[Bug c/24544] New: __gxx_personality_v0
# include
main()
{
printf( "HELLO WORLD\n");
}
If Above is called h.c it compiles if it is called H.C it doesn't. However it
compiles with g++. It seems to me that at compile time H.C is taken to be a C++
programme but at link time it is treated as a C programme. If this is not a bug
it sure acts like one.
gcc H.C produces
Reading specs from /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/specs
Configured with: ../gcc-3.3.4/configure --prefix=/usr --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld
--verbose --target=i486-slackware-linux --host=i486-slackware-linux
Thread model: posix
gcc version 3.3.4
/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/cc1plus -quiet -v -D__GNUC__=3
-D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=4 -D_GNU_SOURCE H.C -D__GNUG__=3
-quiet -dumpbase H.C -auxbase H -version -o /tmp/ccfcrS3x.s
GNU C++ version 3.3.4 (i486-slackware-linux)
compiled by GNU C version 3.3.4.
GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=97018
ignoring nonexistent directory "/usr/i486-slackware-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/qt/include
/usr/include/c++/3.3.4
/usr/include/c++/3.3.4/i486-slackware-linux
/usr/include/c++/3.3.4/backward
/usr/local/include
/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/include
/usr/include
End of search list.
/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/../../../../i486-slackware-linux/bin/as
-V -Qy -o /tmp/ccqbZW7Z.o /tmp/ccfcrS3x.s
GNU assembler version 2.15.92.0.2 (i486-slackware-linux) using BFD version
2.15.92.0.2 20040927
/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/collect2 --eh-frame-hdr -m
elf_i386 -dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/../../../crt1.o
/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/../../../crti.o
/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/crtbegin.o
-L/usr/lib/gcc-lib/i486-slackware-linux/3.3.4
-L/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/../../../../i486-slackware-linux/lib
-L/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/../../.. /tmp/ccqbZW7Z.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/crtend.o
/usr/lib/gcc-lib/i486-slackware-linux/3.3.4/../../../crtn.o
/tmp/ccqbZW7Z.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
--
Summary: __gxx_personality_v0
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: murdochrav at yahoo dot ca
GCC host triplet: i486-slackware-linux
GCC target triplet: i486-slackware-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24544
[Bug driver/24544] __gxx_personality_v0
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-26 16:50 --- This is not a bug. You have to link C++ programs with g++ or link in the libstdc++ library. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |driver Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24544
[Bug fortran/24545] New: gfortran bug regarding interface block with named END INTERFACE statements
Hello, The code example listed at the end of this email fails to compile with gfortran 4.1.0 20051025 (experimental). Compiling like so: gfortran -c gfortran_test.f90 produces the error message: In file gfortran_test.f90:16 END INTERFACE OPERATOR (.EqualTo.) 1 Error: Expecting 'END INTERFACE OPERATOR (.compare_float.)' at (1) This problem with recognizing the end interface statement flows on and produces a whole slew of (spurious) error messages on valid code. If I change the source code line END INTERFACE OPERATOR (.EqualTo.) to simply END INTERFACE the code compiles just fine. However, I believe that using the syntax of END INTERFACE OPERATOR (.EqualTo.) is standard Fortran95. Thanks, paulv --<>-- MODULE Compare_Float_Numbers IMPLICIT NONE PRIVATE PUBLIC :: Compare_Float PUBLIC :: OPERATOR (.EqualTo.) INTERFACE Compare_Float MODULE PROCEDURE Compare_Float_Single MODULE PROCEDURE Compare_Float_Double END INTERFACE Compare_Float INTERFACE OPERATOR (.EqualTo.) MODULE PROCEDURE Is_Equal_To_Single MODULE PROCEDURE Is_Equal_To_Double END INTERFACE OPERATOR (.EqualTo.) INTEGER, PARAMETER :: Single = SELECTED_REAL_KIND(6) ! Single precision INTEGER, PARAMETER :: Double = SELECTED_REAL_KIND(15) ! Double precision CONTAINS ! -- Is Equal To ELEMENTAL FUNCTION Is_Equal_To_Single( x, y ) RESULT( Equal_To ) REAL( Single ), INTENT( IN ) :: x, y LOGICAL :: Equal_To Equal_To = ABS( x - y ) < SPACING( MAX(ABS(x),ABS(y)) ) END FUNCTION Is_Equal_To_Single ELEMENTAL FUNCTION Is_Equal_To_Double( x, y ) RESULT( Equal_To ) REAL( Double ), INTENT( IN ) :: x, y LOGICAL :: Equal_To Equal_To = ABS( x - y ) < SPACING( MAX(ABS(x),ABS(y)) ) END FUNCTION Is_Equal_To_Double ! -- General floating point comparison ELEMENTAL FUNCTION Compare_Float_Single( x, y, ulp ) RESULT( Compare ) REAL( Single ), INTENT( IN ) :: x REAL( Single ), INTENT( IN ) :: y INTEGER,OPTIONAL, INTENT( IN ) :: ulp LOGICAL :: Compare REAL( Single ) :: Rel Rel = 1.0_Single IF ( PRESENT( ulp ) ) THEN Rel = REAL( ABS(ulp), Single ) END IF Compare = ABS( x - y ) < ( Rel * SPACING( MAX(ABS(x),ABS(y)) ) ) END FUNCTION Compare_Float_Single ELEMENTAL FUNCTION Compare_Float_Double( x, y, ulp ) RESULT( Compare ) REAL( Double ), INTENT( IN ) :: x REAL( Double ), INTENT( IN ) :: y INTEGER,OPTIONAL, INTENT( IN ) :: ulp LOGICAL :: Compare REAL( Double ) :: Rel Rel = 1.0_Double IF ( PRESENT( ulp ) ) THEN Rel = REAL( ABS(ulp), Double ) END IF Compare = ABS( x - y ) < ( Rel * SPACING( MAX(ABS(x),ABS(y)) ) ) END FUNCTION Compare_Float_Double END MODULE Compare_Float_Numbers --<>-- -- Summary: gfortran bug regarding interface block with named END INTERFACE statements Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paul dot vandelst at ssec dot wisc dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24545
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-26 16:54 --- (In reply to comment #7) > With the snapshot gcc-4.1-20051022 I get the following additional errors when > I > use --enable-checking=fold and run make check Thanks, that is only one bug now as they all have the following in common, they use address of label extension. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-26 16:54:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug fortran/24534] [4.0/4.1 Regression] PUBLIC derived types with private components
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-26 16:59 --- Confirmed, There might be just some missing check for this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2005-10-26 16:59:36 date|| Summary|gfortran: regression w/ |[4.0/4.1 Regression] PUBLIC |PUBLIC derived types with |derived types with private |private components |components http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24534
[Bug swing/17360] JScrollPane has incorrect size when JList with specified size is added to it
--- Comment #5 from abalkiss at redhat dot com 2005-10-26 17:00 ---
An even more specific test case shows that the problem is in ScrollPaneLayout's
preferredLayoutSize method.
***TESTCASE***
import java.awt.*;
import javax.swing.*;
class Test
{
public static void main(String[] args)
{
String[] items =
{
"Item1", "Item2", "Item3", "Item4", "Item5", "Item6",
"Item7", "Item8", "Item9", "Item10", "Item11"
};
JList list = new JList(items);
list.setPreferredSize(new Dimension(150, 150));
JScrollPane scroller = new JScrollPane(list);
System.out.println (scroller.getLayout().preferredLayoutSize(scroller));
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17360
[Bug fortran/24545] gfortran bug regarding interface block with named END INTERFACE statements
--- Comment #1 from kargl at gcc dot gnu dot org 2005-10-26 17:05 --- Here's a reduced code that shows the problem. Gfortran is not handling the END INTERFACE OPERATOR (.EqualTo.) correctly. This confuses the heck out of the error recovery code. MODULE Compare_Float_Numbers IMPLICIT NONE INTERFACE Compare_Float MODULE PROCEDURE Compare_Float_Single END INTERFACE Compare_Float INTERFACE OPERATOR (.EqualTo.) MODULE PROCEDURE Is_Equal_To_Single END INTERFACE OPERATOR (.EqualTo.) CONTAINS FUNCTION Is_Equal_To_Single(x, y) RESULT(Equal_To) REAL(4), INTENT(IN) :: x, y LOGICAL :: Equal_To Equal_To = .true. END FUNCTION Is_Equal_To_Single FUNCTION Compare_Float_Single(x, y) RESULT(Compare) REAL(4), INTENT(IN) :: x, y LOGICAL :: Compare Compare = .true. END FUNCTION Compare_Float_Single END MODULE Compare_Float_Numbers -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-26 17:05:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24545
[Bug c/24542] potential integer overflow should be warned on assignment to wider variable
--- Comment #5 from alexey at hyperroll dot com 2005-10-26 17:12 --- Sir, it's my first report here, and I see the code first time. I hope that both comments #3 and #4 are not for me. Or am I mistaken? Otherwise, what document (preferably, short) should I read to understand the ideology of the parse tree, and its details. Also, why have I done the parser non-bison compatible? I've taken the stable release, not the CVS revision. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542
[Bug libfortran/24541] libgfortran.so in 4.1 is incompatible with 4.0
--- Comment #6 from steven at gcc dot gnu dot org 2005-10-26 17:46 --- Re. comment #5, yes other library ABIs change too, but libgfortran is special in that what shipped with GCC 4.0 was highly experimental and never intended to be a stable interface. The decision at the time was that breaking it in any way we saw fit for later GCCs was OK until we have something that _is_ stable (i.e. not something we have to call stable just because it was released). I would like to have this PR closed as WONTFIX, but I'll wait for input from other people. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24541
[Bug libgcj/23763] Runtime.getRuntime().exec() signalling
--- Comment #8 from aeby at graeff dot com 2005-10-26 18:04 --- no problem ... I thought, resetting the signal handler to SIG_DFL before unblocking might be a good idea in the (not very probable) case a SIGCHLD signal is either in the signal queue or is otherwise received between sigprocmask() and exec(), just to be safe :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763
[Bug fortran/24546] New: [meta-bug] gfortran debugging problems
This is a meta-bug to catch all gfortran debugging problems. -- Summary: [meta-bug] gfortran debugging problems Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: meta-bug, wrong-debug Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org BugsThisDependsOn: 10220,17905,22244,23057,23280,24526,24527 OtherBugsDependingO 19292 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546
[Bug fortran/24545] gfortran bug regarding interface block with named END INTERFACE statements
--- Comment #2 from steven at gcc dot gnu dot org 2005-10-26 18:54 ---
Perhaps this cures it.
Index: interface.c
===
RCS file: /cvs/gcc/gcc/gcc/fortran/interface.c,v
retrieving revision 1.21
diff -u -3 -p -r1.21 interface.c
--- interface.c 21 Oct 2005 18:50:52 - 1.21
+++ interface.c 26 Oct 2005 18:53:39 -
@@ -295,7 +295,7 @@ gfc_match_end_interface (void)
/* Comparing the symbol node names is OK because only use-associated
symbols can be renamed. */
if (type != current_interface.type
- || strcmp (current_interface.sym->name, name) != 0)
+ || strcmp (current_interface.uop->name, name) != 0)
{
gfc_error ("Expecting 'END INTERFACE OPERATOR (.%s.)' at %C",
current_interface.sym->name);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24545
[Bug swing/17360] JScrollPane has incorrect size when JList with specified size is added to it
--- Comment #6 from abalkiss at redhat dot com 2005-10-26 19:15 --- Created an attachment (id=10064) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10064&action=view) patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17360
[Bug swing/17360] JScrollPane has incorrect size when JList with specified size is added to it
--- Comment #7 from abalkiss at redhat dot com 2005-10-26 19:15 --- Fixed, patch attached. -- abalkiss at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |0.19 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17360
[Bug swing/17362] Scrollbars in JScrollPane appear only if the Container containing JScrollPane is revalidated
--- Comment #4 from abalkiss at redhat dot com 2005-10-26 19:16 --- This has gone backwards and is no longer fixed. -- abalkiss at redhat dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17362
[Bug fortran/21986] Bad .mod file, ICE upon USE
--- Comment #8 from pault at gcc dot gnu dot org 2005-10-26 19:44 --- This was fixed on mainline and 4.0 The testcase now gives: [EMAIL PROTECTED] mytests]# /gcc-clean/bin/gfortran -c pr21986.f90 In file pr21986.f90:4 public:: dummysub ! comment out, lose the bug 1 Error: 'size' is a PRIVATE type and cannot be a dummy argument of 'dummysub', which is PUBLIC at (1) In file pr21986.f90:23 use modboom ! bad .mod file ? 1 Fatal Error: Can't open module file 'modboom.mod' for reading at (1): No such file or directory -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21986
[Bug swing/17362] Scrollbars in JScrollPane appear only if the Container containing JScrollPane is revalidated
--- Comment #5 from abalkiss at redhat dot com 2005-10-26 19:59 --- Created an attachment (id=10065) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10065&action=view) patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17362
[Bug swing/17362] Scrollbars in JScrollPane appear only if the Container containing JScrollPane is revalidated
--- Comment #6 from abalkiss at redhat dot com 2005-10-26 20:00 --- Fixed. -- abalkiss at redhat dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17362
[Bug target/24547] New: Branch cost of -Os is ignored
In i386.c, there are if (optimize_size) ix86_cost = &size_cost; else ix86_cost = processor_target_table[ix86_tune].cost; ... ix86_branch_cost = processor_target_table[ix86_tune].cost->branch_cost; As the result, -Os may generate bigger code than it should have. -- Summary: Branch cost of -Os is ignored Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon 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=24547
[Bug c/24548] New: 3.4 regression: __builtin_constant_p not resolved with -O2
This looks similar to bug 19449, but with just __builtin_constant_p not __builtin_choose_expr so I'm opening a new bug for this. The following code works with 3.3.6, but with 3.4.4 it fails to resolve __builtin_constant_p leading to link errors of unresolved symbols. Code I'm seeing this in is linux 2.6.12 built for arm. The occurance gcc is having problems with is alloc_skb()'s call to kmalloc(). That call is for a non-constant variable (size) so __builtin_constant_p() should result in zero. Problem is present with -O2, however -O1 is resolving __builtin_constant_p correctly. I'll attach full preprocessed output as well as compiled output. Compile line is: arm-linux-gcc -Wp,-MD,net/core/.skbuff.o.d -nostdinc -isystem /net/gia/djohnson/tools/usr/local/starent/bintools/linux-arm/gcc/200510261510/lib/gcc/arm-linux/3.4.4/include -D__KERNEL__ -Iinclude -mbig-endian -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -O2 -fno-omit-frame-pointer -g -fno-omit-frame-pointer -mapcs -mno-sched-prolog -mapcs-32 -D__LINUX_ARM_ARCH__=5 -march=armv5te -mtune=xscale -Wa,-mcpu=xscale -malignment-traps -msoft-float -Uarm -Wdeclaration-after-statement -DKBUILD_BASENAME=skbuff -DKBUILD_MODNAME=skbuff -c -o net/core/.tmp_skbuff.o net/core/skbuff.c arm-linux-nm net/core/.tmp_skbuff.o |grep that_much U __you_cannot_kmalloc_that_much -- Summary: 3.4 regression: __builtin_constant_p not resolved with - O2 Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: djohnson+gcc at sw dot starentnetworks dot com GCC build triplet: i686-linux GCC host triplet: i686-linux GCC target triplet: arm-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24548
[Bug c/24548] 3.4 regression: __builtin_constant_p not resolved with -O2
--- Comment #1 from djohnson+gcc at sw dot starentnetworks dot com 2005-10-26 20:55 --- Created an attachment (id=10066) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10066&action=view) preprocessed output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24548
[Bug c/24548] 3.4 regression: __builtin_constant_p not resolved with -O2
--- Comment #2 from djohnson+gcc at sw dot starentnetworks dot com 2005-10-26 20:56 --- Created an attachment (id=10067) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10067&action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24548
[Bug middle-end/24548] 3.4 regression: __builtin_constant_p not resolved with -O2
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-26 21:25 --- I don't think this is a GCC bug as what is happening is that something is being inlined which did not get inlined before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24548
[Bug fortran/24549] New: gfortran: IMPORT of f2003 not yet implemented, ICE
Hi, the IMPORT statement of Fortran2003 is not yet implemented. Trying to use it provokes an ICE: module gfcbug29_import integer, parameter :: dp = kind (1d0) interface subroutine foo (x) import :: dp real (kind=dp) :: x end subroutine foo end interface end module gfcbug29_import % gfortran -c -std=f2003 gfcbug29.f90 In file gfcbug29.f90:6 import :: dp 1 Error: Unclassifiable statement at (1) gfcbug29.f90:0: internal compiler error: Segmentation fault See the Fortran2003 draft, tables 2.1, 2.2, and section 12.3.2.1 about interface blocks. Cheers, -ha -- Summary: gfortran: IMPORT of f2003 not yet implemented, ICE Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24549
[Bug preprocessor/8270] [3.4/4.0/4.1 Regression] back-slash newline extension can't be removed
--- Comment #29 from pinskia at gcc dot gnu dot org 2005-10-26 21:41 --- Hmm, there consense is that at the least we should warn for comments. But the consense from non Apple people it seems to not to change the behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
[Bug preprocessor/8270] [3.4/4.0/4.1 Regression] back-slash newline extension can't be removed
--- Comment #30 from echristo at apple dot com 2005-10-26 21:46 --- That would be the consensus from Andrew, not from people concerned that deal with language issues routinely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
[Bug preprocessor/8270] [3.4/4.0/4.1 Regression] back-slash newline extension can't be removed
--- Comment #31 from pinskia at gcc dot gnu dot org 2005-10-26 21:49 --- (In reply to comment #30) > That would be the consensus from Andrew, not from people concerned that deal > with language issues routinely. Wait a minute, if you actually look at the people agrueing for the change, it is only Apple employees. Joe has said we should not change it. It looks like DJ is saying the same in the new thread which shows the real issues with the other compilers implemenation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
libgloss psignal declaration [PATCH]
I found the following patch necessary to build libiberty with newlib
headers. Although, glibc seems to use the same signature now.
Cheers,
Shaun
2005-10-26 Shaun Jackman <[EMAIL PROTECTED]>
* libiberty/strsignal.c (psignal): Change the signo parameter from
unsigned to int, and message from char * to const char*.
Index: libiberty/strsignal.c
===
RCS file: /cvs/src/src/libiberty/strsignal.c,v
retrieving revision 1.9
diff -u -r1.9 strsignal.c
--- libiberty/strsignal.c 28 Mar 2005 02:09:01 - 1.9
+++ libiberty/strsignal.c 26 Oct 2005 21:56:29 -
@@ -549,7 +549,7 @@
#ifndef HAVE_PSIGNAL
void
-psignal (unsigned signo, char *message)
+psignal (int signo, const char *message)
{
if (signal_names == NULL)
{
[Bug tree-optimization/24365] [4.1 Regression] statement makes a memory store with complex
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-26 22:38 --- This is a combined return slot optimization and inliner bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot ||org, hubicka at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24365
[Bug middle-end/24362] [4.0/4.1 Regression] internal compiler error: in extract_component, at tree-complex.c:68
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-26 22:42 --- I have the simple/obvious patch which fixes this one at least the issue in this PR and not the one in PR 24365 so this will still not work on the mainline. -- 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=24362
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complex
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-26 22:51 --- Note in the mathematical sense complex numbers are scalars, I know in the compiler world this is different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
Re: [Bug preprocessor/8270] [3.4/4.0/4.1 Regression] back-slash newline extension can't be removed
pinskia at gcc dot gnu dot org wrote:- > > That would be the consensus from Andrew, not from people concerned that deal > > with language issues routinely. > > Wait a minute, if you actually look at the people agrueing for the change, it > is only Apple employees. Joe has said we should not change it. It looks like > DJ is saying the same in the new thread which shows the real issues with the > other compilers implemenation. I've said we should change it, I don't work for Apple. Please stop trying to claim your opinion is some kind of consensus. Neil.
[Bug preprocessor/8270] [3.4/4.0/4.1 Regression] back-slash newline extension can't be removed
--- Comment #32 from neil at daikokuya dot co dot uk 2005-10-26 23:07 --- Subject: Re: [3.4/4.0/4.1 Regression] back-slash newline extension can't be removed pinskia at gcc dot gnu dot org wrote:- > > That would be the consensus from Andrew, not from people concerned that deal > > with language issues routinely. > > Wait a minute, if you actually look at the people agrueing for the change, it > is only Apple employees. Joe has said we should not change it. It looks like > DJ is saying the same in the new thread which shows the real issues with the > other compilers implemenation. I've said we should change it, I don't work for Apple. Please stop trying to claim your opinion is some kind of consensus. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
[Bug preprocessor/8270] [3.4/4.0/4.1 Regression] back-slash newline extension can't be removed
--- Comment #33 from dj at redhat dot com 2005-10-26 23:13 --- Subject: Re: [3.4/4.0/4.1 Regression] back-slash newline extension can't be removed > It looks like DJ is saying the same in the new thread which shows > the real issues with the other compilers implemenation. I would be in favor of treating \r differently from other whitespace for the purposes of reporting this error. The cr-lf-newline mess is different from the trailing space mess. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
Re: libgloss psignal declaration [PATCH]
> I found the following patch necessary to build libiberty with newlib
> headers. Although, glibc seems to use the same signature now.
While I'm generally OK with this...
1. The patch is incomplete, as you don't update the documentation to
match the new prototype.
2. GCC patches go to [EMAIL PROTECTED]
3. If you have a psignal prototype, you should have a psignal
function, and thus should not be compiling this code at all. Thus,
something else is broken. Look for newlib-specific code in
configure.ac.
I suggest leaving the prototype as-is until #3 is resolved, since the
conflict tells you when it's still broken.
> Cheers,
> Shaun
>
> 2005-10-26 Shaun Jackman <[EMAIL PROTECTED]>
>
> * libiberty/strsignal.c (psignal): Change the signo parameter from
> unsigned to int, and message from char * to const char*.
>
> Index: libiberty/strsignal.c
> ===
> RCS file: /cvs/src/src/libiberty/strsignal.c,v
> retrieving revision 1.9
> diff -u -r1.9 strsignal.c
> --- libiberty/strsignal.c 28 Mar 2005 02:09:01 - 1.9
> +++ libiberty/strsignal.c 26 Oct 2005 21:56:29 -
> @@ -549,7 +549,7 @@
> #ifndef HAVE_PSIGNAL
>
> void
> -psignal (unsigned signo, char *message)
> +psignal (int signo, const char *message)
> {
>if (signal_names == NULL)
> {
>
[Bug rtl-optimization/23392] [4.1 Regression] foward-1.m fails with -funroll-loops -O3 -fgnu-runtime
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-27 00:08 --- CCing Zdenek as he introduced this regression by enabling rename registers for unrolling loops. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
[Bug tree-optimization/21559] [4.1 Regression] missed jump threading
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-27 00:12 --- I should note that this is a true code gen regression and not just a missed one at the tree level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21559
