[Bug target/39002] codegen bug, stack pointer is not restored
--- Comment #14 from ubizjak at gmail dot com 2009-01-29 08:05 --- Cc the author of the patch: Author: hubicka Date: Tue Jan 6 15:08:44 2009 New Revision: 143119 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143119 Log: * i386.h (CONDITIONAL_CALL_USAGE): SSE regs are not used for w64 ABI. * i386.c (struct ix86_frame): Add padding0 and nsseregs. (ix86_nsaved_regs): Count only general purpose regs. (ix86_nsaved_sseregs): New. (ix86_compute_frame_layout): Update nsseregs; set preferred alignment to 16 for w64; compute padding and size of sse reg save area. (ix86_emit_save_regs, ix86_emit_save_regs_using_mov): Save only general purpose regs. (ix86_emit_save_sse_regs_using_mov): New. (ix86_expand_prologue): Save SSE regs if needed. (ix86_emit_restore_regs_using_mov): Use only general purpose regs. (ix86_emit_restore_sse_regs_using_mov): New. (ix86_expand_epilogue): Save SSE regs if needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h -- ubizjak at gmail dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|WAITING |NEW Component|c++ |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-29 08:05:29 date|| Summary|codegen bug?|codegen bug, stack pointer ||is not restored http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug target/39002] [4,4 Regression] codegen bug, stack pointer is not restored
--- Comment #15 from ubizjak at gmail dot com 2009-01-29 08:06 --- 4.4 regression. -- ubizjak at gmail dot com changed: What|Removed |Added Summary|codegen bug, stack pointer |[4,4 Regression] codegen |is not restored |bug, stack pointer is not ||restored Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug lto/39016] New: [LTO] ICE in output_expr_operand because of BLOCK Expressions.
From running the testsuite and for the testcase 20021204-1.c /home/ramana/cos/build-try/gcc/cc1 -fpreprocessed 20021204-1.i -quiet -dumpbase 20021204-1.c -mtune=generic -auxbase-strip 20021204-1.o -O1 -w -version -flto -o 20021204-1.s #0 fancy_abort (file=0xa888740 P\207\210\nP\207\210\n\t, line=9, function=0xa888740 P\207\210\nP\207\210\n\t) at ../../lto/gcc/diagnostic.c:711 #1 0x0879703d in output_expr_operand (ob=0xa88a278, expr=0xb7805f50) at ../../lto/gcc/lto-function-out.c:1200 #2 0x08799303 in output_local_vars (ob=0xa88a278, fn=value optimized out) at ../../lto/gcc/lto-function-out.c:1373 #3 0x0879eabe in lto_output (set=0xb7794f0c) at ../../lto/gcc/lto-function-out.c:1968 #4 0x082dd8d9 in ipa_write_summaries_2 (pass=0x8a3fb40, set=0xb7794f0c, state=0xa88e718) at ../../lto/gcc/passes.c:1403 #5 0x082de7c2 in ipa_write_summaries_1 (set=0xb7794f0c) at ../../lto/gcc/passes.c:1428 #6 0x082de8aa in ipa_write_summaries () at ../../lto/gcc/passes.c:1449 #7 0x08577e08 in cgraph_optimize () at ../../lto/gcc/cgraphunit.c:1266 #8 0x0805f51b in c_write_global_declarations () at ../../lto/gcc/c-decl.c:8045 #9 0x08389399 in toplev_main (argc=15, argv=0xbfa31754) at ../../lto/gcc/toplev.c:991 #10 0x080d8a0b in main (argc=15, argv=0xbfa31754) at ../../lto/gcc/main.c:35 (gdb) p debug_tree (expr) block 0xb7805f50 used supercontext function_decl 0xb781e780 q type function_type 0xb7824144 type integer_type 0xb779d2f4 int QI size integer_cst 0xb778e508 constant 8 unit size integer_cst 0xb778e524 constant 1 align 8 symtab 0 alias set -1 canonical type 0xb77a7798 pointer_to_this pointer_type 0xb78241b0 addressable used static no-static-chain decl_5 QI file /home/ramana/cos/lto/gcc/testsuite/gcc.c-torture/compile/20021204-1.c line 8 col 7 align 8 initial block 0xb7805f50 result result_decl 0xb7796230 D.1233 type integer_type 0xb779d2f4 int ignored SI file /home/ramana/cos/lto/gcc/testsuite/gcc.c-torture/compile/20021204-1.c line 8 col 3 size integer_cst 0xb778e690 constant 32 unit size integer_cst 0xb778e47c constant 4 align 32 context function_decl 0xb781e780 q saved-insns 0xb77990fc $5 = void There was a similar bug reported for #39000 but that is for fdesc expressions on ia64 . -- Summary: [LTO] ICE in output_expr_operand because of BLOCK Expressions. Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ramana dot r at gmail dot com GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39016
[Bug middle-end/39015] [4.3 regression] wrong code building libgsf
--- Comment #1 from jdassen at debian dot org 2009-01-29 09:10 --- Created an attachment (id=17206) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17206action=view) The (gtk-doc-tools generated) gsf-scan.c file which gets miscompiled -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug middle-end/39015] [4.3 regression] wrong code building libgsf
--- Comment #2 from jdassen at debian dot org 2009-01-29 09:11 --- Created an attachment (id=17207) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17207action=view) The (gtk-doc-tools generated) gsf-scan.c file which gets miscompiled, preprocessed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug c++/38908] [4.4 regression] Unexplained 'anonymous' is used uninitialized in this function warning in cc1plus -m64
--- Comment #14 from rguenther at suse dot de 2009-01-29 09:19 ---
Subject: Re: [4.4 regression] Unexplained 'anonymous' is
used uninitialized in this function warning in cc1plus -m64
On Wed, 28 Jan 2009, mmitchel at gcc dot gnu dot org wrote:
--- Comment #13 from mmitchel at gcc dot gnu dot org 2009-01-28 23:56
---
Actually, CLASSTYPE_EMPTY_P is probably a fine thing to use for C++. (It's of
course C++ specific; you'd either need to access it via a hook, or promote to
a
language-independent bit.) CLASSTYPE_EMPTY_P will not capture an array of
empty objects, but that's an extreme corner-case.
Note that CLASSTYPE_EMPTY_P classes may have arbitrary size. That's because
of
things like:
struct A{};
struct B : public A {};
struct C : public A, public B {};
In C, you cannot put the B sub-object at the same address as the A sub-object
since that would end up with two A sub-objects (the A-in-B-in-C subobject and
A-in-C subobject) at the same address. So, C will be a two-byte structure.
Obviously, you can generalize this to make arbitrarily huge empty classes.
Ok. But, as opposed to inheritance, inserting empty members seems to
make a class non-empty:
struct A {};
struct B { A x; };
even if in the single-member case I would have expected it to behave
like the single-inheritance case really. Note that cp_expr_size boils
down to checking CLASSTYPE_EMPTY_P already, but in the member case
doesn't seem to map to does not need initialization.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38908
[Bug c/39013] Missing @PLT when -fpie is used
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-01-29 09:56 --- No compiler with -fpie support manages to do this correct. Not a regression. IMHO this is invalid. 6.7.4/6 ... If a function is declared with an inline function specifier, then it shall also be defined in the same translation unit. which is obviously not the case here. That is C99 of course, so you might argue that for GNU C89 the situation should be different, but then the frontend should properly mark the declaration extern. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|target |c Keywords||accepts-invalid Known to fail||3.4.6 Summary|[4.3/4.4 regression] Missing|Missing @PLT when -fpie is |@PLT when -fpie is used |used http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39013
[Bug c/39013] Missing @PLT when -fpie is used
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Target Milestone|4.3.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39013
[Bug middle-end/39015] [4.3 regression] wrong code building libgsf
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-29 10:01 --- The best option would be to revert that patch on the branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||sje at gcc dot gnu dot org, ||rguenth at gcc dot gnu dot ||org Priority|P3 |P1 Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug middle-end/38969] [4.3 Regression] -foptimize-sibling-calls generates wrong code on alpha
--- Comment #8 from uros at gcc dot gnu dot org 2009-01-29 10:05 --- Subject: Bug 38969 Author: uros Date: Thu Jan 29 10:05:17 2009 New Revision: 143752 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143752 Log: Backport from mainline: 2009-01-28 Uros Bizjak ubiz...@gmail.com PR target/38988 * gcc.target/i386/pr38988.c: New test. 2009-01-27 Uros Bizjak ubiz...@gmail.com PR middle-end/38969 * gcc.c-torture/execute/pr38969.c: New test. testsuite/ChangeLog: Backport from mainline: 2009-01-28 Uros Bizjak ubiz...@gmail.com PR target/38988 * config/i386/i386.md (set_rip_rex64): Wrap operand 1 in label_ref. (set_got_offset_rex64): Ditto. 2009-01-27 Uros Bizjak ubiz...@gmail.com PR middle-end/38969 * calls.c (initialize_argument_information): Do not wrap complex arguments in SAVE_EXPR. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr38969.c - copied unchanged from r143699, trunk/gcc/testsuite/gcc.c-torture/execute/pr38969.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr38988.c - copied unchanged from r143720, trunk/gcc/testsuite/gcc.target/i386/pr38988.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/calls.c branches/gcc-4_3-branch/gcc/config/i386/i386.md branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38969
[Bug target/38988] Cannot build crtstuff.c with -mcmodel=large -fPIC -O2
--- Comment #11 from uros at gcc dot gnu dot org 2009-01-29 10:05 --- Subject: Bug 38988 Author: uros Date: Thu Jan 29 10:05:17 2009 New Revision: 143752 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143752 Log: Backport from mainline: 2009-01-28 Uros Bizjak ubiz...@gmail.com PR target/38988 * gcc.target/i386/pr38988.c: New test. 2009-01-27 Uros Bizjak ubiz...@gmail.com PR middle-end/38969 * gcc.c-torture/execute/pr38969.c: New test. testsuite/ChangeLog: Backport from mainline: 2009-01-28 Uros Bizjak ubiz...@gmail.com PR target/38988 * config/i386/i386.md (set_rip_rex64): Wrap operand 1 in label_ref. (set_got_offset_rex64): Ditto. 2009-01-27 Uros Bizjak ubiz...@gmail.com PR middle-end/38969 * calls.c (initialize_argument_information): Do not wrap complex arguments in SAVE_EXPR. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr38969.c - copied unchanged from r143699, trunk/gcc/testsuite/gcc.c-torture/execute/pr38969.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr38988.c - copied unchanged from r143720, trunk/gcc/testsuite/gcc.target/i386/pr38988.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/calls.c branches/gcc-4_3-branch/gcc/config/i386/i386.md branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38988
[Bug target/38988] Cannot build crtstuff.c with -mcmodel=large -fPIC -O2
--- Comment #12 from ubizjak at gmail dot com 2009-01-29 10:09 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38988
[Bug middle-end/38969] [4.3 Regression] -foptimize-sibling-calls generates wrong code on alpha
--- Comment #9 from ubizjak at gmail dot com 2009-01-29 10:10 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38969
[Bug middle-end/39015] [4.3 regression] wrong code building libgsf
--- Comment #4 from doko at ubuntu dot com 2009-01-29 10:14 --- when Ray wrote he tested with a snapshot build, I assume this was 20090107 without the patch applied, so the status on the trunk is not known yet. will test with current trunk later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug middle-end/39015] [4.3 regression] wrong code building libgsf
--- Comment #5 from jdassen at debian dot org 2009-01-29 10:24 --- (In reply to comment #4) when Ray wrote he tested with a snapshot build, I assume this was 20090107 without the patch applied, Yes, I was using sid's gcc-snapshot 20090107-1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #16 from jakub at gcc dot gnu dot org 2009-01-29 10:31 --- Created an attachment (id=17208) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17208action=view) gcc44-pr39002.patch As MS_ABI sseregs save area isn't counted into frame.allocate anymore, IMHO ix86_can_use_return_insn_p has to check for that too. This patch cures the testcase for visual inspection. Could somebody please bootstrap/regtest it on mingw? I can bootstrap/regtest it on x86_64-linux, but as nsseregs is always zero there, this won't be sufficient test. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug libmudflap/38339] libtool: compile: not configured to build any kind of library
--- Comment #12 from gzp at gmx dot net 2009-01-29 10:43 --- Anyone knows how 'i686-pc-linux-gnu/libmudflap/libtool' file generated? Thats the problem, and still is with released 4.3.3. -- gzp at gmx dot net changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38339
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #17 from r dot emrich at de dot tecosim dot com 2009-01-29 10:47 --- (In reply to comment #16) Created an attachment (id=17208) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17208action=view) [edit] gcc44-pr39002.patch As MS_ABI sseregs save area isn't counted into frame.allocate anymore, IMHO ix86_can_use_return_insn_p has to check for that too. This patch cures the testcase for visual inspection. Could somebody please bootstrap/regtest it on mingw? I can bootstrap/regtest it on x86_64-linux, but as nsseregs is always zero there, this won't be sufficient test. I can will do my cross build and test in the afternoon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug middle-end/38857] [4.4 Regression] ICE in selective scheduler
--- Comment #9 from amonakov at gcc dot gnu dot org 2009-01-29 10:53 --- Subject: Bug 38857 Author: amonakov Date: Thu Jan 29 10:53:15 2009 New Revision: 143753 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143753 Log: 2009-01-29 Andrey Belevantsev a...@ispras.ru Alexander Monakov amona...@ispras.ru PR middle-end/38857 * sel-sched.c (count_occurrences_1): Check that *cur_rtx is a hard register. (move_exprs_to_boundary): Change return type and pass through should_move from move_op. Relax assert. Update usage ... (schedule_expr_on_boundary): ... here. Use should_move instead of cant_move. (move_op_orig_expr_found): Indicate that insn was disconnected from stream. (code_motion_process_successors): Do not call after_merge_succs callback if original expression was not found when traversing any of the branches. (code_motion_path_driver): Change return type. Update prototype. (move_op): Update comment. Add a new parameter (should_move). Update prototype. Set *should_move based on indication provided by move_op_orig_expr_found. 2009-01-29 Steve Ellcey s...@cup.hp.com PR middle-end/38857 * gcc.c-torture/compile/pr38857.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr38857.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38857
[Bug middle-end/38857] [4.4 Regression] ICE in selective scheduler
--- Comment #10 from amonakov at gcc dot gnu dot org 2009-01-29 10:55 --- Fixed with above commit. -- amonakov at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38857
[Bug c++/38625] Segmentation fault when dereferencing valid pointer, probably REGRESSION
--- Comment #11 from l dot jirkovsky at gmail dot com 2009-01-29 11:19 --- First, I'd like to thank you for doing this hard work and for finding out which patch causes this problem. Anyway I've done more investigation to the problematic code. The problem actually begins in CachedFileImageIteratorBase::operator*() In correct build (without optimizations, with debugging enabled or with --param inline-unit-growth=60) the currentRow pointer is pointer to ordinary array, I'm guessing it's array of unsigned shorts. But in segfaulting build my debugger (gdb) shows me, that currentRow is: vigra::TinyVectorBaseunsigned char, 3, unsigned char [3], vigra::TinyVectorunsigned char, 3 which _data structure doesn't exist in memory. Because it deems really weird I'm not sure the debugger was right (it was run with higly optimized code when only some parts of enblend actually had debugging information on). However if I'm wrong in previous statement, the currentRow should still be valid. I'd took if I was trying to access, lets say, currentRow[1000] which could be out of array bounds, but this code segfaults when I'm trying to access currentRow[0]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38625
[Bug c++/37037] [4.2/4.3/4.4 Regression] ICE on template class member function definition after explciit template class instantation
--- Comment #5 from paolo dot carlini at oracle dot com 2009-01-29 11:23 --- Are we really sure this is invalid? For one, EDG doesn't agree... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37037
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #18 from r dot emrich at de dot tecosim dot com 2009-01-29 11:34 --- (In reply to comment #17) (In reply to comment #16) Created an attachment (id=17208) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17208action=view) [edit] gcc44-pr39002.patch As MS_ABI sseregs save area isn't counted into frame.allocate anymore, IMHO ix86_can_use_return_insn_p has to check for that too. This patch cures the testcase for visual inspection. Could somebody please bootstrap/regtest it on mingw? I can bootstrap/regtest it on x86_64-linux, but as nsseregs is always zero there, this won't be sufficient test. I can will do my cross build and test in the afternoon. Solves my problem. But I can't run the testsuite, because I don't have a sufficient setup. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug c++/39017] New: ice for legal C++ with -O3
I just tried to compile the Suse Linux package kde4-k3b-4.1.4.svn907132-1.5 with the g++ compiler version 4.4 snapshot 20090123. The compiler said /usr/src/packages/BUILD/k3b/libk3b/tools/k3blibdvdcss.cpp:109: internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:2769 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed C++ source code attached. Flag -O3 required. -- Summary: ice for legal C++ with -O3 Product: gcc Version: 4.4.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: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39017
[Bug c++/39017] ice for legal C++ with -O3
--- Comment #1 from dcb314 at hotmail dot com 2009-01-29 11:53 --- Created an attachment (id=17209) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17209action=view) C++source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39017
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #19 from jakub at gcc dot gnu dot org 2009-01-29 12:03 --- Anyone else could test it, please? -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org, dannysmith at gcc dot ||gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #20 from ktietz at gcc dot gnu dot org 2009-01-29 12:21 --- (In reply to comment #19) Anyone else could test it, please? I am currently on to test it for w64. We noticed a regression reasoned by this for this target, too (sadly we found it pretty late). This patch seems fine, but I guess that in ix86_expand_epilogue also the checks for frame.nregs should be altered to (frame.nregs + frame.nsseregs), too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #21 from ktietz at gcc dot gnu dot org 2009-01-29 12:27 --- Created an attachment (id=17210) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17210action=view) Alternative patch suggested This is the patch I test at the moment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug testsuite/38946] [4.4 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #14 from rob1weld at aol dot com 2009-01-29 12:32 ---
(In reply to comment #5)
! Test XFAILed on these platforms because the system's printf() lacks
! proper support for denormalized long doubles. See PR24685
Looks like this testcase should be xfailed on solaris also.
(In reply to comment #9)
Subject: Re: [trunk regression]?gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously
I think adding a printf() clone to libiberty is WAY overkill just to
silence one failing test.
I took a look around for some existing tests that could help us.
The files:
gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-*
gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-scanf-*
are setup only for mingw. I added OpenSolaris and got this result:
Mod:
/* { dg-do compile { target { *-*-mingw* } } } */
/* { dg-do compile { target { *-*-mingw* *-*-solaris2.11* } } } */
Result:
FAIL: gcc.dg/format/ms_c90-printf-1.c (test for excess errors)
Excess errors:
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-1.c:56:
warning: use of 'h' length modifier with 'c' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-1.c:57:
warning: use of 'h' length modifier with 's' type character
FAIL: gcc.dg/format/ms_c90-printf-2.c %hh is unsupported (test for warnings,
line 17)
FAIL: gcc.dg/format/ms_c90-printf-2.c %j is unsupported (test for warnings,
line 19)
FAIL: gcc.dg/format/ms_c90-printf-2.c %z is unsupported (test for warnings,
line 20)
FAIL: gcc.dg/format/ms_c90-printf-2.c %t is unsupported (test for warnings,
line 21)
FAIL: gcc.dg/format/ms_c90-printf-2.c (test for excess errors)
Excess errors:
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:17:
warning: ISO C90 does not support the 'hh' gnu_printf length modifier
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:18:
warning: format '%I64d' expects type 'int', but argument 2 has type 'llong'
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:19:
warning: ISO C90 does not support the 'j' gnu_printf length modifier
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:20:
warning: ISO C90 does not support the 'z' gnu_printf length modifier
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:21:
warning: ISO C90 does not support the 't' gnu_printf length modifier
FAIL: gcc.dg/format/ms_c90-printf-2.c -DWIDE %hh is unsupported (test for
warnings, line 17)
FAIL: gcc.dg/format/ms_c90-printf-2.c -DWIDE %j is unsupported (test for
warnings, line 19)
FAIL: gcc.dg/format/ms_c90-printf-2.c -DWIDE %z is unsupported (test for
warnings, line 20)
FAIL: gcc.dg/format/ms_c90-printf-2.c -DWIDE %t is unsupported (test for
warnings, line 21)
FAIL: gcc.dg/format/ms_c90-printf-2.c -DWIDE (test for excess errors)
Excess errors:
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:17:
warning: ISO C90 does not support the 'hh' gnu_printf length modifier
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:18:
warning: format '%I64d' expects type 'int', but argument 2 has type 'llong'
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:19:
warning: ISO C90 does not support the 'j' gnu_printf length modifier
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:20:
warning: ISO C90 does not support the 'z' gnu_printf length modifier
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:21:
warning: ISO C90 does not support the 't' gnu_printf length modifier
FAIL: gcc.dg/format/ms_c90-scanf-1.c %L is unsupported (test for warnings,
line 75)
FAIL: gcc.dg/format/ms_c90-scanf-1.c %L is unsupported (test for warnings,
line 76)
FAIL: gcc.dg/format/ms_c90-scanf-1.c %L is unsupported (test for warnings,
line 77)
FAIL: gcc.dg/format/ms_c90-scanf-1.c %L is unsupported (test for warnings,
line 78)
FAIL: gcc.dg/format/ms_c90-scanf-1.c %L is unsupported (test for warnings,
line 79)
FAIL: gcc.dg/format/ms_c90-scanf-1.c (test for excess errors)
Excess errors:
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-scanf-1.c:56:
warning: use of 'h' length modifier with 's' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-scanf-1.c:58:
warning: use of 'h' length modifier with 'c' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-scanf-1.c:75:
warning: use of 'L' length modifier with 's' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-scanf-1.c:76:
warning: use of 'L' length modifier with '[' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-scanf-1.c:77:
warning: use of 'L' length modifier with 'c' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-scanf-1.c:78:
warning: use of 'L' length modifier with 'p' type character
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #22 from ktietz at gcc dot gnu dot org 2009-01-29 12:52 --- (In reply to comment #21) Created an attachment (id=17210) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17210action=view) [edit] Alternative patch suggested This is the patch I test at the moment. The patch I posted works for w64 without any regressions. For linux64 it needs to be tested, too. I have here at work no linux64 box. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization
--- Comment #20 from danglin at gcc dot gnu dot org 2009-01-29 13:05 --- hppa just uses the generic code for delayed branch optimization. The target problems that led to this PR were fixed in this series of changes: 2009-01-05 John David Anglin dave.ang...@nrc-cnrc.gc.ca * pa.c (output_call): Relocate non-jump insns in the delay slot of long absolute calls when generating PA 2.0 code. 2009-01-09 John David Anglin dave.ang...@nrc-cnrc.gc.ca * pa.c (last_address): Change to unsigned. (update_total_code_bytes): Change argument to unsigned. Don't check if insn addresses are set. (pa_output_function_epilogue): Set last_address to UINT_MAX if insn addresses are not set. (pa_asm_output_mi_thunk): Handle wrap when updating last_address. 2009-01-12 John David Anglin dave.ang...@nrc-cnrc.gc.ca * pa.c (pa_asm_output_mi_thunk): Use pc-relative branch to thunk function when not using named sections on targets with named sections if branch distance is less than 262132. All three are installed on 4.3.3 and trunk. Only the first, the most critical one, is on 4.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #23 from jakub at gcc dot gnu dot org 2009-01-29 13:23 --- I don't see why ix86_expand_epilogue should be changed. Do you have some testcase which shows where your change improves generated code? I can certainly test on Linux, but as frame.nsseregs is always 0 there, it should make zilch difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug c++/39018] New: Cannot take address of template function
The following code fails to compile under g++ 4.3.2:
class Bar {};
templateint N
class Foo {
double val[N];
};
templateint N
void fun(FooN* ptr) {
}
typedef void (*T)(Bar*);
T funptr = (T) fun2;
The error message is:
$ g++ -c a.cc
a.cc:14: error: address of overloaded function with no contextual type
information
I don't know if the standard allows this, but it looks like it should be
allowed to take the address of a templated function, because it works in other
contexts (see below). It seems unambiguous because with foo2 we a specific
variant of the function is requested. Intel's C++ compiler (icpc versions 9.1
and 10.1) accepts it.
It is possible to work around this error by providing contextual type
information, although how to do that is not immediately obvious to everyone.
The workaround that worked for me is to replace the last line with:
typedef void (*U)(Foo2*);
T funptr = (T) (U) fun2;
which compiles without errors or warnings.
The error is similar to bug 29143, but I don't think it's a dup. In that case,
the contextual type information is present, but apparently ignored by the
compiler. In this case, context doesn't help with type determination, but it
shouldn't be necessary since foo2 uniquely identifies the function.
Detailed version information:
$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)
--
Summary: Cannot take address of template function
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hniksic at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39018
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #24 from ktietz at gcc dot gnu dot org 2009-01-29 13:45 --- (In reply to comment #23) I don't see why ix86_expand_epilogue should be changed. Do you have some testcase which shows where your change improves generated code? I can certainly test on Linux, but as frame.nsseregs is always 0 there, it should make zilch difference. It is the same testcase for w64. Just the option -fno-omit-frame-pointer has to be added. This leads on w64 to an ICE (internal abort) without this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #25 from jakub at gcc dot gnu dot org 2009-01-29 13:54 --- Can't reproduce that with a cross compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #26 from ktietz at gcc dot gnu dot org 2009-01-29 14:04 --- (In reply to comment #25) Can't reproduce that with a cross compiler. You are right, I changed something else, too. Sorry. But this patch to expand_epilogue is proper IIUC Comment tells If we're only restoring one register and sp is not valid then using a move instruction to restore the register since it's less work than reloading sp and popping the register. ... for w64 the can be more then one register in use but the check in the if doesn't verify this, and produces therefore slower code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug middle-end/35854] [4.3/4.4 Regression] life passes dump option still documented
--- Comment #6 from zadeck at gcc dot gnu dot org 2009-01-29 14:35 --- Subject: Bug 35854 Author: zadeck Date: Thu Jan 29 14:34:55 2009 New Revision: 143756 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143756 Log: 2009-01-29 Kenneth Zadeck zad...@naturalbridge.com PR middle-end/35854 * doc/invoke.texi (rtl debug options): Complete rewrite. * auto-inc-dec.c (pass_inc_dec): Rename pass from auto-inc-dec to auto_inc_dec. * mode-switching.c (pass_mode_switching): Rename pass from mode-sw to mode_sw. * except.c (pass_convert_to_eh_ranges): Rename pass from eh-ranges to eh_ranges. * lower-subreg.c (pass_lower_subreg): Renamed pass from subreg to subreg1. 2009-01-29 Kenneth Zadeck zad...@naturalbridge.com PR middle-end/35854 * gcc.dg/lower-subreg-1.c: Renamed dump pass from subreg to subreg1 Modified: trunk/gcc/ChangeLog trunk/gcc/auto-inc-dec.c trunk/gcc/doc/invoke.texi trunk/gcc/except.c trunk/gcc/lower-subreg.c trunk/gcc/mode-switching.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/lower-subreg-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35854
[Bug ada/38989] How much stack space should c380004 take?
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-01-29 14:37 --- RTEMS has fixed size task stacks. This test is blowing a stack that is ~100K large. How large does it need to be? Is is a bug to use this much stack? It's a QOI issue, the stack usage is already capped (see exp_ch9.adb). -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38989
[Bug middle-end/35854] [4.3/4.4 Regression] life passes dump option still documented
--- Comment #7 from zadeck at naturalbridge dot com 2009-01-29 14:38
---
Subject: Re: [4.3/4.4 Regression] life passes dump
option still documented
Richard Guenther wrote:
On Wed, Jan 28, 2009 at 5:03 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
rguenth at gcc dot gnu dot org wrote:
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-24 10:20
---
GCC 4.3.3 is being released, adjusting target milestone.
This may be more a change than is acceptable right now for 4.4. If so
I will sit on this patch until 4.5 opens up. The patch is basically a
complete rewrite of the part of invoke.texi that deals with dump options
for the rtl pass. This section had badly rotted.
I started from a grep of the sources looking for rtl_opt_pass and
documented all of the passes that i found in mostly alphabetical
order. Where the old version documented several passes together, I
kept that unless things had changed. In total there were about a half
dozen passes that were no longer there and about a dozen new passes that
had not been documented.
I did make some changes in the code, which is the reason that this may
not be acceptable to 4.4. The changes are pretty harmless: all of them
involve either removing the pass name or changing it.
1) Pass names that contained dashes had the dashes changed to
underscores. About half used slashes and half underscores and I went
with underscores to avoid a possible ambiguity with the options parsing.
2) I also removed the pass name from 6 passes that do not print anything
or dump the code.
I think this change is agains what was asked for in the past. We want to have
pass names for all passes.
3) Files that contained multiple passes with names of the form xx,
xx2... were renamed xx1,xx2.
This later change causes a test suit failure which was fixed.
All of these changes are pretty minor. The only possible failure these
can cause are in the test suite where dump files are scanned.
I tested this on x86 and ppc both 32 and 64. It is possible that there
are platform specific regression tests that scan for dump files that
were not caught on these four targets.
I also left in lreg and greg.These are at the end and need to be
deleted along with those passes.
I have enclosed a copy of the new text. The diff is unreadable.
ok for 4.4 or should i wait for 4.5?
This is ok for 4.4 if you remove the parts that remove pass names. Please
wait a day for comments from others.
Thanks,
Richard.
I put those pass names back, but I documented them as producing no
output. I also removed the lreg and greg part since the RA removal
patch has been approved.
committed as revision 143756
kenny
2009-01-29 Kenneth Zadeck zad...@naturalbridge.com
PR middle-end/35854
* doc/invoke.texi (rtl debug options): Complete rewrite.
* auto-inc-dec.c (pass_inc_dec): Rename pass from auto-inc-dec
to auto_inc_dec.
* mode-switching.c (pass_mode_switching): Rename pass from
mode-sw to mode_sw.
* except.c (pass_convert_to_eh_ranges): Rename pass from
eh-ranges to eh_ranges.
* lower-subreg.c (pass_lower_subreg): Renamed pass from subreg
to subreg1.
2009-01-29 Kenneth Zadeck zad...@naturalbridge.com
PR middle-end/35854
* gcc.dg/lower-subreg-1.c: Renamed dump pass from subreg to
subreg1
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 143754)
+++ doc/invoke.texi (working copy)
@@ -4545,172 +4545,275 @@ preprocessing.
Debug dumps can be enabled with a @option{-fdump-rtl} switch or some
@option{-d} option @var{letters}. Here are the possible
-letters for use in @var{letters} and @var{pass}, and their meanings:
+letters for use in @var{pass} and @var{letters}, and their meanings:
@table @gcctabopt
-...@item -dA
-...@opindex dA
-Annotate the assembler output with miscellaneous debugging information.
+
+...@item -fdump-rtl-alignments
+...@opindex fdump-rtl-alignments
+Dump after branch alignments have been computed.
+
+...@item -fdump-rtl-asmcons
+...@opindex fdump-rtl-asmcons
+Dump after fixing rtl statements that have unsatisfied in/out constraints.
+
+...@item -fdump-rtl-auto_inc_dec
+...@opindex fdump-rtl-auto_inc_dec
+Dump after auto-inc-dec discovery. This pass is only run on
+architectures that have auto inc or auto dec instructions.
+
+...@item -fdump-rtl-barriers
+...@opindex fdump-rtl-barriers
+Dump after cleaning up the barrier instructions.
+
+...@item -fdump-rtl-bbpart
+...@opindex fdump-rtl-bbpart
+Dump after partitioning hot and cold basic blocks.
@item -fdump-rtl-bbro
@opindex fdump-rtl-bbro
-Dump after block reordering, to @fi...@var{file}.148r.bbro}.
+Dump after block reordering.
+
+...@item -fdump-rtl-btl1
+...@itemx -fdump-rtl-btl2
+...@opindex fdump-rtl-btl2
+...@opindex fdump-rtl-btl2
+...@option{-fdump-rtl-btl1} and
[Bug middle-end/35854] [4.3/4.4 Regression] life passes dump option still documented
--- Comment #8 from zadeck at naturalbridge dot com 2009-01-29 14:42 --- patch committed. closed for 4.4. richi said not to backport to 4.3 on irc. -- zadeck at naturalbridge dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35854
[Bug middle-end/35854] [4.3/4.4 Regression] life passes dump option still documented
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.4 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35854
[Bug c++/39017] ice for legal C++ with -O3
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-29 14:50 --- This is likely a dup of PR38926 which was fixed Jan 28th. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39017
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #41 from rob1weld at aol dot com 2009-01-29 15:01 --- (In reply to comment #35) In response to comment #34, the -B option overrides GCC_EXEC_PREFIX and the compiler being tested in the build directory is invoked with -B. GCC_EXEC_PREFIX will only be used to find files that are not in the build directory. It causes a few problems and is (obviously?) incorrect. Proof: To _exactly_ reproduce the conditions may not be necessary but here they are: Compile, test and install the trunk (from early this year) on an Athlon-X2. You likely need to ./configure with additional options, I believe that --with-tune=k8 --with-cpu=k8 --with-arch=k8 would be the minimum. The full list is at the end of this page: http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02197.html Update your source with contrib/gcc_update and rebuild (it is possible to use that script and not reconfigure but you may if you wish). Now, do NOT Install gcc. Run make -i check and when it is complete rename or copy the log. # mv gcc_build/gcc/testsuite/gcc/gcc.log gcc_build/gcc/testsuite/gcc/gcc.log.PREVIOUS Now, run make install. Run make -i check and when it is complete do this: # ../gcc_trunk/contrib/compare_tests ../gcc_build/gcc/testsuite/gcc/gcc.log.PREVIOUS_1 ../gcc_build/gcc/testsuite/gcc/gcc.log New tests that FAIL: gcc.target/i386/funcspec-3.c scan-assembler call\t(.*)popcountdi2 gcc.target/i386/funcspec-3.c scan-assembler popcntq New tests that PASS: gcc.target/i386/funcspec-3.c scan-assembler call\t(.*)sse42_pop_l gcc.target/i386/funcspec-3.c scan-assembler call\t(.*)sse4a_pop_i gcc.target/i386/funcspec-3.c scan-assembler popcntl gcc.target/i386/funcspec-3.c (test for excess errors) That is the Official Log Comparison Script and it reports a difference on the result of make -i check on an un-installed gcc versus an installed gcc. Can I say This is P1, all test results suspect, most invalid. ? Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug target/39013] Missing @PLT when -fpie is used
--- Comment #11 from zorry at ume dot nu 2009-01-29 15:03 --- I don't get the link error with gcc 4.2.4 on the code in comment #7 -- zorry at ume dot nu changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39013
[Bug target/39013] [4.3/4.4 Regression] Missing @PLT when -fpie is used
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-29 15:20
---
My testcase is
cat t2.c
void foo() {}
cat t.c
inline void foo ();
int main ()
{
foo ();
return 0;
}
which works perfectly fine even with 4.3 and 4.4 if I build both t2.c and t.c
with -fpie and fails with all compilers supporting -fpie if I only build
t.c with -fpie but t2.c not.
They bind locally with 4.3 and 4.4 though.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|accepts-invalid |
Known to fail|3.4.6 |4.3.3 4.4.0
Known to work||4.2.4
Summary|Missing @PLT when -fpie is |[4.3/4.4 Regression] Missing
|used|@PLT when -fpie is used
Target Milestone|--- |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39013
[Bug target/39013] [4.3/4.4 Regression] Missing @PLT when -fpie is used
--- Comment #13 from hjl dot tools at gmail dot com 2009-01-29 15:52
---
(In reply to comment #12)
My testcase is
cat t2.c
void foo() {}
The problem happens when t2.c is in a shared library.
cat t.c
inline void foo ();
int main ()
{
foo ();
return 0;
}
which works perfectly fine even with 4.3 and 4.4 if I build both t2.c and t.c
with -fpie and fails with all compilers supporting -fpie if I only build
t.c with -fpie but t2.c not.
We can argue that this code is invalid and gcc shouldn't accept it
in the first place. But from user perspective, gcc 4.3 doesn't work
on their codes any more silently.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39013
[Bug target/39013] [4.3/4.4 Regression] Missing @PLT when -fpie is used
--- Comment #14 from hjl dot tools at gmail dot com 2009-01-29 15:53 --- Created an attachment (id=17211) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17211action=view) A patch This patch only checks --- gcc/varasm.c.pie2008-11-30 08:49:54.0 -0800 +++ gcc/varasm.c2009-01-29 07:50:46.0 -0800 @@ -6321,6 +6321,10 @@ default_binds_local_p_1 (const_tree exp, (DECL_INITIAL (exp) == NULL || DECL_INITIAL (exp) == error_mark_node)) local_p = false; + /* Functions without body are not local. */ + else if (TREE_CODE (exp) == FUNCTION_DECL + DECL_INITIAL (exp) == NULL) +local_p = false; /* Otherwise we're left with initialized (or non-common) global data which is of necessity defined locally. */ else -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39013
[Bug bootstrap/39019] New: Solaris and IRIX libelf cause trouble for build
Despite they seem to have the same interface, the libelf bundled with Solaris
(at
least as far back as Solaris 8) cause trouble:
* The Solaris libelf.h isn't largefile aware:
#if defined(_ILP32) (_FILE_OFFSET_BITS != 32)
#error large files are not supported by libelf
#endif
This is explained in detail in
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/sgs/libelf/common/README.LFS
* IRIX 6.5 has libelf.h, too, but lacks gelf.h.
* When I use libelf 0.8.10 instead (installed into /vol/gcc/{include, lib}),
I have to be very careful: using CPPFLAGS=-I/vol/gcc/include doesn't work
since libelf.h is preferred and thus the copy in /usr/include is used. Using
-I/vol/gcc/include/libelf doesn't work either since gelf.h includes
libelf/libelf.h which isn't found than. One needs to use
-I/vol/gcc/include/libelf -I/vol/gcc/include, which is intricate to get
right.
I think the use of libelf should be handled similarly to gmp/mpfr via
--with-libelf or some such.
--
Summary: Solaris and IRIX libelf cause trouble for build
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: dnovillo at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.11
GCC host triplet: sparc-sun-solaris2.11
GCC target triplet: sparc-sun-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39019
[Bug bootstrap/39020] New: lto-plugin requires visibility support
The lto plugin currently requires a bootstrap compiler with visibility support: /vol/gcc/src/gcc-lto/lto-plugin/../gcc/lto/common.c:25: warning: visibility attribute not supported in this configuration; ignored Since it is built with -Werror, this causes a bootstrap failure if that support is missing. This causes problems for Solaris, since the necessary support only went in in December last year. -- Summary: lto-plugin requires visibility support Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: dnovillo at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2.11 GCC host triplet: sparc-sun-solaris2.11 GCC target triplet: sparc-sun-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39020
[Bug bootstrap/39021] New: lto requires GCC as bootstrap compiler
At least gcc/lto/common.c makes unconditional use of __attribute__ ((visibility (hidden))), which means you are forced to use GCC as a bootstrap compiler. If building lto and the lto-plugin were moved to stage2, this wouldn't be a problem. -- Summary: lto requires GCC as bootstrap compiler Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: dnovillo at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2.11 GCC host triplet: sparc-sun-solaris2.11 GCC target triplet: sparc-sun-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39021
[Bug tree-optimization/39007] -ftree-loop-distribution ICEs
--- Comment #2 from kazu at gcc dot gnu dot org 2009-01-29 16:11 --- Patch posted. -- kazu at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||01/msg01449.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39007
[Bug bootstrap/39022] New: lto-plugin is built unconditionally
I just noticed that lto-plugin is only used with gold, but is built unconditionally. This may unnecessarily break builds and should be avoided. -- Summary: lto-plugin is built unconditionally Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: dnovillo at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39022
[Bug bootstrap/39023] New: lto-plugin.c uses mkdtemp unconditionally
lto-plugin.c uses mkdtemp unconditionally, which breaks Solaris 10/x86 bootstrap where this function is missing (while it was introduced for Solaris 11). There should be a replacement, but the fix for PR bootstrap/39022 would avoid this since gold currently cannot be used on non-GNU/Linux configurations (cf. PR gold/7024). -- Summary: lto-plugin.c uses mkdtemp unconditionally Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: dnovillo at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39023
[Bug bootstrap/39024] New: static libelf needs to be built PIC
I had built the prerequisite libelf 0.8.10 for lto statically to avoid RPATH issues, but noticed that by default liblto_plugin.so.0 failed to link since libelf.a contained non-PIC code. Building with -fPIC fixed this, but the requirement better be documented. -- Summary: static libelf needs to be built PIC Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: dnovillo at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2.11 GCC host triplet: sparc-sun-solaris2.11 GCC target triplet: sparc-sun-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39024
[Bug middle-end/39015] [4.3 regression] wrong code building libgsf
--- Comment #6 from sje at cup dot hp dot com 2009-01-29 17:00 --- What GCC options was gsf-scan.i compiled with? I am trying to see what variables are getting/not getting promoted during the compilation and I am not seeing it affect any variables if I just compile gsf-scan.i with -O[0123]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug tree-optimization/38926] [4.4 Regression] ice in find_or_generate_expression, at tree-ssa-pre.c:2769
--- Comment #10 from hjl at gcc dot gnu dot org 2009-01-29 17:06 --- Subject: Bug 38926 Author: hjl Date: Thu Jan 29 17:06:01 2009 New Revision: 143762 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143762 Log: 2009-01-29 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-01-29 Steve Ellcey s...@cup.hp.com PR middle-end/38857 * gcc.c-torture/compile/pr38857.c: New test. 2009-01-28 Richard Guenther rguent...@suse.de PR tree-optimization/38926 * gcc.c-torture/compile/pr38926.c: New testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/pr38857.c - copied unchanged from r143760, trunk/gcc/testsuite/gcc.c-torture/compile/pr38857.c branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/pr38926.c - copied unchanged from r143759, trunk/gcc/testsuite/gcc.c-torture/compile/pr38926.c Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38926
[Bug middle-end/38857] [4.4 Regression] ICE in selective scheduler
--- Comment #11 from hjl at gcc dot gnu dot org 2009-01-29 17:06 --- Subject: Bug 38857 Author: hjl Date: Thu Jan 29 17:06:01 2009 New Revision: 143762 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143762 Log: 2009-01-29 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-01-29 Steve Ellcey s...@cup.hp.com PR middle-end/38857 * gcc.c-torture/compile/pr38857.c: New test. 2009-01-28 Richard Guenther rguent...@suse.de PR tree-optimization/38926 * gcc.c-torture/compile/pr38926.c: New testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/pr38857.c - copied unchanged from r143760, trunk/gcc/testsuite/gcc.c-torture/compile/pr38857.c branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/pr38926.c - copied unchanged from r143759, trunk/gcc/testsuite/gcc.c-torture/compile/pr38926.c Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38857
[Bug bootstrap/39025] New: ICE in start_function, at c-decl.c:6225 while configuring libgcc
The configure step of libgcc aborts with
checking for suffix of object files... configure: error: in
`/vol/gccsrc/obj/gcc-lto-20090127/11-gcc/sparc-sun-solaris2.11/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
config.log reveals
configure:2590: checking for suffix of object files
configure:2611: /vol/gccsrc/obj/gcc-lto-20090127/11-gcc/./gcc/xgcc
-B/vol/gccsrc/obj/gcc-lto-20090127/11-gcc/./gcc/
-B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/
-isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem
/vol/gcc/sparc-sun-solaris2.11/sys-include -c -g -O2conftest.c 5
conftest.c:16: internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
configure:2614: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME GNU C Runtime Library
| #define PACKAGE_TARNAME libgcc
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING GNU C Runtime Library 1.0
| #define PACKAGE_BUGREPORT
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2627: error: in
`/vol/gccsrc/obj/gcc-lto-20090127/11-gcc/sparc-sun-solaris2.11/libgcc':
configure:2629: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Running cc1 on this conftest.c gives
% ./cc1 conftest.c
main
conftest.c:5: internal compiler error: in start_function, at c-decl.c:6225
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
The same problem happens on i386-pc-solaris2.10.
--
Summary: ICE in start_function, at c-decl.c:6225 while
configuring libgcc
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: dnovillo at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.11
GCC host triplet: sparc-sun-solaris2.11
GCC target triplet: sparc-sun-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39025
[Bug target/37364] [4.4 Regression] IRA generates inefficient code due to missing regmove pass
--- Comment #32 from hjl dot tools at gmail dot com 2009-01-29 17:13 --- This has been fixed by revision 143757: http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01410.html -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug c++/38908] [4.4 regression] Unexplained 'anonymous' is used uninitialized in this function warning in cc1plus -m64
--- Comment #15 from hjl at gcc dot gnu dot org 2009-01-29 17:43 --- Subject: Bug 38908 Author: hjl Date: Thu Jan 29 17:43:14 2009 New Revision: 143765 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143765 Log: 2009-01-29 H.J. Lu hongjiu...@intel.com 2009-01-28 Richard Guenther rguent...@suse.de PR middle-end/38908 * g++.dg/warn/Wuninitialized-2.C: New testcase. 2009-01-27 Daniel Kraft d...@domob.eu PR fortran/38883 * gfortran.dg/mvbits_6.f90: New test. * gfortran.dg/mvbits_7.f90: New test. * gfortran.dg/mvbits_8.f90: New test. 2009-01-21 Daniel Kraft d...@domob.eu PR fortran/38887 * gfortran.dg/mvbits_5.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/Wuninitialized-2.C - copied unchanged from r143764, trunk/gcc/testsuite/g++.dg/warn/Wuninitialized-2.C branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/mvbits_5.f90 - copied unchanged from r143764, trunk/gcc/testsuite/gfortran.dg/mvbits_5.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/mvbits_6.f90 - copied unchanged from r143764, trunk/gcc/testsuite/gfortran.dg/mvbits_6.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/mvbits_7.f90 - copied unchanged from r143764, trunk/gcc/testsuite/gfortran.dg/mvbits_7.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/mvbits_8.f90 - copied unchanged from r143764, trunk/gcc/testsuite/gfortran.dg/mvbits_8.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38908
[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts
--- Comment #9 from hjl at gcc dot gnu dot org 2009-01-29 17:43 --- Subject: Bug 38883 Author: hjl Date: Thu Jan 29 17:43:14 2009 New Revision: 143765 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143765 Log: 2009-01-29 H.J. Lu hongjiu...@intel.com 2009-01-28 Richard Guenther rguent...@suse.de PR middle-end/38908 * g++.dg/warn/Wuninitialized-2.C: New testcase. 2009-01-27 Daniel Kraft d...@domob.eu PR fortran/38883 * gfortran.dg/mvbits_6.f90: New test. * gfortran.dg/mvbits_7.f90: New test. * gfortran.dg/mvbits_8.f90: New test. 2009-01-21 Daniel Kraft d...@domob.eu PR fortran/38887 * gfortran.dg/mvbits_5.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/Wuninitialized-2.C - copied unchanged from r143764, trunk/gcc/testsuite/g++.dg/warn/Wuninitialized-2.C branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/mvbits_5.f90 - copied unchanged from r143764, trunk/gcc/testsuite/gfortran.dg/mvbits_5.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/mvbits_6.f90 - copied unchanged from r143764, trunk/gcc/testsuite/gfortran.dg/mvbits_6.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/mvbits_7.f90 - copied unchanged from r143764, trunk/gcc/testsuite/gfortran.dg/mvbits_7.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/mvbits_8.f90 - copied unchanged from r143764, trunk/gcc/testsuite/gfortran.dg/mvbits_8.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883
[Bug fortran/38887] [4.4 Regression] run-time abort for MVBITS with run-time zero sized array arguments
--- Comment #6 from hjl at gcc dot gnu dot org 2009-01-29 17:43 --- Subject: Bug 38887 Author: hjl Date: Thu Jan 29 17:43:14 2009 New Revision: 143765 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143765 Log: 2009-01-29 H.J. Lu hongjiu...@intel.com 2009-01-28 Richard Guenther rguent...@suse.de PR middle-end/38908 * g++.dg/warn/Wuninitialized-2.C: New testcase. 2009-01-27 Daniel Kraft d...@domob.eu PR fortran/38883 * gfortran.dg/mvbits_6.f90: New test. * gfortran.dg/mvbits_7.f90: New test. * gfortran.dg/mvbits_8.f90: New test. 2009-01-21 Daniel Kraft d...@domob.eu PR fortran/38887 * gfortran.dg/mvbits_5.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/Wuninitialized-2.C - copied unchanged from r143764, trunk/gcc/testsuite/g++.dg/warn/Wuninitialized-2.C branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/mvbits_5.f90 - copied unchanged from r143764, trunk/gcc/testsuite/gfortran.dg/mvbits_5.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/mvbits_6.f90 - copied unchanged from r143764, trunk/gcc/testsuite/gfortran.dg/mvbits_6.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/mvbits_7.f90 - copied unchanged from r143764, trunk/gcc/testsuite/gfortran.dg/mvbits_7.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/mvbits_8.f90 - copied unchanged from r143764, trunk/gcc/testsuite/gfortran.dg/mvbits_8.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38887
Re: [Bug middle-end/39015] [4.3 regression] wrong code building libgsf
Sent from my iPhone On Jan 29, 2009, at 2:01 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-29 10:01 --- The best option would be to revert that patch on the branch. Except it alone could not cause wrong code. Some other pass is causing it. And then again with a testcase it is hard to figure out what is going wrong. That patch just disables one small optimization in one case. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --- --- -- CC||sje at gcc dot gnu dot org, ||rguenth at gcc dot gnu dot ||org Priority|P3 |P1 Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug middle-end/39015] [4.3 regression] wrong code building libgsf
--- Comment #7 from jdassen at debian dot org 2009-01-29 17:53 --- (In reply to comment #3) The best option would be to revert that patch on the branch. Matthias did that in the 4.3.3-3 packages and with them, the problem has indeed gone away. (In reply to comment #6) What GCC options was gsf-scan.i compiled with? compile line: /bin/sh ../libtool --mode=compile cc -Wl,-z,defs -Wl,-O1 -Wl,--as-needed -O2 -Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare -DG_DISABLE_DEPRECATED -Wno-system-headers -Wfloat-equal -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wformat -Wnested-externs -Winline -Wdeclaration-after-statement -Wundef -W -Wmissing-noreturn -Wmissing-format-attribute -Wno-pointer-sign -DLIBGSF_GNOMEVFS_VIA_GIO -I../.. -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -O2 -Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare -DG_DISABLE_DEPRECATED -Wno-system-headers -Wfloat-equal -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wformat -Wnested-externs -Winline -Wdeclaration-after-statement -Wundef -W -Wmissing-noreturn -Wmissing-format-attribute -Wno-pointer-sign -DLIBGSF_GNOMEVFS_VIA_GIO -c -o gsf-scan.lo gsf-scan.c link line: /bin/sh ../libtool --mode=link cc -Wl,-z,defs -Wl,-O1 -Wl,--as-needed -O2 -Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare -DG_DISABLE_DEPRECATED -Wno-system-headers -Wfloat-equal -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wformat -Wnested-externs -Winline -Wdeclaration-after-statement -Wundef -W -Wmissing-noreturn -Wmissing-format-attribute -Wno-pointer-sign -DLIBGSF_GNOMEVFS_VIA_GIO -no-undefined -o gsf-scan gsf-scan.lo ../gsf/libgsf-1.la -lgobject-2.0 -lglib-2.0 -lxml2 -no-undefined -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug middle-end/39015] [4.3 regression] wrong code building libgsf
--- Comment #8 from pinskia at gmail dot com 2009-01-29 17:53 --- Subject: Re: [4.3 regression] wrong code building libgsf Sent from my iPhone On Jan 29, 2009, at 2:01 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-29 10:01 --- The best option would be to revert that patch on the branch. Except it alone could not cause wrong code. Some other pass is causing it. And then again with a testcase it is hard to figure out what is going wrong. That patch just disables one small optimization in one case. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --- --- -- CC||sje at gcc dot gnu dot org, ||rguenth at gcc dot gnu dot ||org Priority|P3 |P1 Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug target/37364] [4.4 Regression] IRA generates inefficient code due to missing regmove pass
--- Comment #33 from hjl dot tools at gmail dot com 2009-01-29 17:57 --- Reopen since revision 143757 isn't supposed to fix it. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
[Bug tree-optimization/39007] -ftree-loop-distribution ICEs
--- Comment #3 from kazu at gcc dot gnu dot org 2009-01-29 18:23 --- Subject: Bug 39007 Author: kazu Date: Thu Jan 29 18:23:21 2009 New Revision: 143767 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143767 Log: gcc/ PR tree-optimization/39007 * tree-loop-distribution.c (generate_builtin): Use recompute_dominator to compute the immediate dominator of the basic block just after the loop. gcc/testsuite/ PR tree-optimization/39007 * gcc.dg/tree-ssa/pr39007.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr39007.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-loop-distribution.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39007
[Bug target/39013] [4.3/4.4 Regression] Missing @PLT when -fpie is used
--- Comment #15 from zorry at ume dot nu 2009-01-29 18:23 ---
We have this in the shared library that is compile with -fPIC
inline u_int32_t
libnet_getgre_length(u_int16_t fv)
{
code
}
And the app have
code
len = libnet_getgre_length(gre_flags);
size += len;
code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39013
[Bug c/39026] New: Gcc accepts invalid code
+++ This bug was initially created as a clone of Bug #39013 +++
[...@gnu-6 gcc]$ cat /tmp/i.i
inline void foo ();
int
main ()
{
foo ();
return 0;
}
[...@gnu-6 gcc]$ gcc /tmp/i.i -S
Is this valid C code? From
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39013#c10
--
IMHO this is invalid. 6.7.4/6
... If a function is declared with an inline function specifier, then it
shall also be defined in the same translation unit.
--
--
Summary: Gcc accepts invalid code
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
BugsThisDependsOn: 39013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39026
[Bug tree-optimization/39007] -ftree-loop-distribution ICEs
--- Comment #4 from kazu at gcc dot gnu dot org 2009-01-29 18:31 --- Fixed. -- kazu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39007
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #42 from janis at gcc dot gnu dot org 2009-01-29 18:32 --- I'm looking into this. It's all very messy and confusing, so I'm trying to step back and understand the big picture. Is there a reason that GCC_EXEC_PREFIX is set to $(libdir)/gcc/ for the compiler tests but not for the library tests? Is is a problem that HOSTCC uses LD_LIBRARY_PATH set for the compiler under test? -- janis at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janis at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-07-15 14:41:05 |2009-01-29 18:32:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug c/39026] Gcc accepts invalid code
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-29 18:34 --- Icc 11.0 gave: [...@gnu-6 tmp]$ /opt/intel/cce/11.0/bin/icc -S i.i-Wall i.i(1): remark #1419: external declaration in primary source file inline void foo (); ^ [...@gnu-6 tmp]$ /opt/intel/cce/11.0/bin/icc -S i.i [...@gnu-6 tmp]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39026
[Bug middle-end/39015] [4.3 regression] wrong code building libgsf
--- Comment #9 from sje at cup dot hp dot com 2009-01-29 18:57 --- So far I have been unable to reproduce this problem. When compiling gsf-scan.i I do not even reach the code that I changed in PR 38615 and I get the same code with or without my change included. Assuming there is a way to trigger this, I wonder if the program is legal. In particular I was looking at the initialization of GbArgTable which has a lot of holes in it. If the optimization affects whether or not these holes get set to zero and if the program is accessing these uninitialized locations that could cause a change in behaviour. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug c/39027] New: double floating point suffix of 'd' and 'D' not accepted
With C command line option -std=gnu99 double floating-point constants with either 'd' or 'D' suffix are not accepted by gcc 4.3.2-7 running on Intel x86/x87 Pentium 4 running Fedora Core 10 Linux Part of gcc -v is: gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) #define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */ double d1 = 1.0d; /* binary double (yes) versus decimal double (no) */ double d2 = 2.0D; gets error: invalid suffix d on floating constant error: invalid suffix D on floating constant -- Summary: double floating point suffix of 'd' and 'D' not accepted Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tydeman at tybor dot com GCC host triplet: 4.3.2 GCC target triplet: 4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39027
[Bug target/39027] double floating point suffix of 'd' and 'D' not accepted
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-29 19:38 --- I think you need to configure GCC with DFP support. Defining __STDC_WANT_DEC_FP__ is not enough. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39027
[Bug middle-end/38157] -fconserve-stack enabled by default
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38157
[Bug c/39026] Gcc accepts invalid code
--- Comment #2 from joseph at codesourcery dot com 2009-01-29 20:02 ---
Subject: Re: New: Gcc accepts invalid code
On Thu, 29 Jan 2009, hjl dot tools at gmail dot com wrote:
inline void foo ();
int
main ()
{
foo ();
return 0;
}
[...@gnu-6 gcc]$ gcc /tmp/i.i -S
If you use -std=c99 -pedantic-errors you get an error, as expected.
You're compiling in gnu89 mode.
If you use -std=c99 without -pedantic-errors you get a duplicate warning:
t.c:1: warning: inline function 'foo' declared but never defined
t.c:1: warning: inline function 'foo' declared but never defined
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39026
[Bug c++/39028] New: C++ front-end rejects __label__ at the beginning of a block after for and while
Trying to compile the c++ program label.C
void c ()
{ for (;;) {__label__ l; goto l; l:;}
while (1) {__label__ l; goto l; l:;}
if (1) {__label__ l; goto l; l:;}
do {__label__ l; goto l; l:;} while (1);
{__label__ l; goto l; l:;}
}
using
g++ -Wall -Wextra -c label.C
with g++ versions 4.4.0 20090129 (experimental) and 4.3.3 gives:
label.C: In function 'void c()':
label.C:2: error: '__label__' not at the beginning of a block
label.C:3: error: '__label__' not at the beginning of a block
label.C:3: error: duplicate label 'l'
The fix for bug 32121 C++ front-end accepts invalid __label__
declarations (svn revision 129253) moved handling __label__ declarations
to function cp_parser_compound_statement in gcc/cp/parser.c and omitted
it in function cp_parser_already_scoped_statement. The newly introduced
tests cases only check the error case for while and for statements,
unfortunately.
Without any deeper understanding of gcc internals, I suggest two
possible fixes:
- copy the two lines handling __label__ declarations
from function cp_parser_compound_statement to function
cp_parser_already_scoped_statement, which might be the smallest change or
- merge part of cp_parser_already_scoped_statement's functionality to
cp_parser_compound_statement avoiding code duplication.
--
Summary: C++ front-end rejects __label__ at the beginning of a
block after for and while
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: springl-gcc at bfw-online dot de
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=39028
Re: [Bug c/39026] New: Gcc accepts invalid code
On Thu, 29 Jan 2009, hjl dot tools at gmail dot com wrote:
inline void foo ();
int
main ()
{
foo ();
return 0;
}
[...@gnu-6 gcc]$ gcc /tmp/i.i -S
If you use -std=c99 -pedantic-errors you get an error, as expected.
You're compiling in gnu89 mode.
If you use -std=c99 without -pedantic-errors you get a duplicate warning:
t.c:1: warning: inline function 'foo' declared but never defined
t.c:1: warning: inline function 'foo' declared but never defined
--
Joseph S. Myers
jos...@codesourcery.com
[Bug c/39026] Gcc accepts invalid code
--- Comment #3 from hjl dot tools at gmail dot com 2009-01-29 20:09 --- (In reply to comment #2) If you use -std=c99 -pedantic-errors you get an error, as expected. You're compiling in gnu89 mode. If you use -std=c99 without -pedantic-errors you get a duplicate warning: t.c:1: warning: inline function 'foo' declared but never defined t.c:1: warning: inline function 'foo' declared but never defined So the code is valid in gnu89 mode, which is the default. With -std=c99 and without -pedantic-errors, shouldn't we generate working binary? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39026
[Bug c++/39028] [4.3/4.4 Regression] C++ front-end rejects __label__ at the beginning of a block after for and while
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||rejects-valid Summary|C++ front-end rejects |[4.3/4.4 Regression] C++ |__label__ at the beginning|front-end rejects |of a block after for and |__label__ at the beginning |while |of a block after for and ||while Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39028
Attachments for gcc bugzilla entry #39028
Hi,
I just wanted to upload the attached files to gcc bugzilla entry #39028,
but I always hit a bugzilla bug. Could you please attach these files to
the bug for me?
Thank you.
Regards
Stephancommit a9f24d7b25568b3fde13ae406deb1aeeacf45e23
Author: Stephan Springl stephan-...@springl.homeip.net
Date: Thu Jan 29 20:00:31 2009 +0100
fix
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 5baf5f5..e5bc7f7 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -153,6 +153,13 @@ typedef struct cp_token_cache GTY(())
cp_token * GTY ((skip)) last;
} cp_token_cache;
+enum cp_scope_begin
+{
+ cp_scope_begin_do,
+ cp_scope_begin_try,
+ cp_scope_begin_dont
+};
+
/* Prototypes. */
static cp_lexer *cp_lexer_new_main
@@ -1639,7 +1646,7 @@ static void cp_parser_label_for_labeled_statement
static tree cp_parser_expression_statement
(cp_parser *, tree);
static tree cp_parser_compound_statement
- (cp_parser *, tree, bool);
+ (cp_parser *, tree, enum cp_scope_begin);
static void cp_parser_statement_seq_opt
(cp_parser *, tree);
static tree cp_parser_selection_statement
@@ -3243,7 +3250,7 @@ cp_parser_primary_expression (cp_parser *parser,
/* Start the statement-expression. */
expr = begin_stmt_expr ();
/* Parse the compound-statement. */
- cp_parser_compound_statement (parser, expr, false);
+ cp_parser_compound_statement (parser, expr, cp_scope_begin_do);
/* Finish up. */
expr = finish_stmt_expr (expr, false);
}
@@ -6959,7 +6966,7 @@ cp_parser_statement (cp_parser* parser, tree in_statement_expr,
}
/* Anything that starts with a `{' must be a compound-statement. */
else if (token-type == CPP_OPEN_BRACE)
-statement = cp_parser_compound_statement (parser, NULL, false);
+statement = cp_parser_compound_statement (parser, NULL, cp_scope_begin_do);
/* CPP_PRAGMA is a #pragma inside a function body, which constitutes
a statement all its own. */
else if (token-type == CPP_PRAGMA)
@@ -7143,22 +7150,25 @@ cp_parser_expression_statement (cp_parser* parser, tree in_statement_expr)
static tree
cp_parser_compound_statement (cp_parser *parser, tree in_statement_expr,
- bool in_try)
+ enum cp_scope_begin scope_begin)
{
- tree compound_stmt;
+ tree compound_stmt = NULL_TREE;
/* Consume the `{'. */
if (!cp_parser_require (parser, CPP_OPEN_BRACE, %{%))
return error_mark_node;
/* Begin the compound-statement. */
- compound_stmt = begin_compound_stmt (in_try ? BCS_TRY_BLOCK : 0);
+ if (scope_begin != cp_scope_begin_dont)
+compound_stmt = begin_compound_stmt (scope_begin == cp_scope_begin_try ?
+ BCS_TRY_BLOCK : 0);
/* If the next keyword is `__label__' we have a label declaration. */
while (cp_lexer_next_token_is_keyword (parser-lexer, RID_LABEL))
cp_parser_label_declaration (parser);
/* Parse an (optional) statement-seq. */
cp_parser_statement_seq_opt (parser, in_statement_expr);
/* Finish the compound-statement. */
- finish_compound_stmt (compound_stmt);
+ if (scope_begin != cp_scope_begin_dont)
+finish_compound_stmt (compound_stmt);
/* Consume the `}'. */
cp_parser_require (parser, CPP_CLOSE_BRACE, %}%);
@@ -7812,7 +7822,7 @@ cp_parser_implicitly_scoped_statement (cp_parser* parser, bool *if_p)
}
/* if a compound is opened, we simply parse the statement directly. */
else if (cp_lexer_next_token_is (parser-lexer, CPP_OPEN_BRACE))
-statement = cp_parser_compound_statement (parser, NULL, false);
+statement = cp_parser_compound_statement (parser, NULL, cp_scope_begin_do);
/* If the token is not a `{', then we must take special action. */
else
{
@@ -7840,13 +7850,7 @@ cp_parser_already_scoped_statement (cp_parser* parser)
if (cp_lexer_next_token_is_not (parser-lexer, CPP_OPEN_BRACE))
cp_parser_statement (parser, NULL_TREE, false, NULL);
else
-{
- /* Avoid calling cp_parser_compound_statement, so that we
- don't create a new scope. Do everything else by hand. */
- cp_parser_require (parser, CPP_OPEN_BRACE, %{%);
- cp_parser_statement_seq_opt (parser, NULL_TREE);
- cp_parser_require (parser, CPP_CLOSE_BRACE, %}%);
-}
+cp_parser_compound_statement (parser, NULL, cp_scope_begin_dont);
}
/* Declarations [gram.dcl.dcl] */
@@ -14464,7 +14468,7 @@ cp_parser_default_argument (cp_parser *parser, bool template_parm_p)
static void
cp_parser_function_body (cp_parser *parser)
{
- cp_parser_compound_statement (parser, NULL, false);
+ cp_parser_compound_statement (parser, NULL, cp_scope_begin_do);
}
/* Parse a ctor-initializer-opt followed by a function-body. Return
@@ -16374,7 +16378,7 @@ cp_parser_try_block (cp_parser* parser)
cp_parser_require_keyword (parser, RID_TRY, %try%);
try_block = begin_try_block ();
- cp_parser_compound_statement (parser, NULL, true);
+ cp_parser_compound_statement (parser, NULL, cp_scope_begin_try);
finish_try_block (try_block);
[Bug pch/39029] New: #pragma once is not exported from the precompiled headers
When precompiling, #pragma once directives are handled correctly, but once we try to use the pch, these directives are lost and the compiler will #include again every real header file, even if it's already contained in the pch file. The easy workaround is to fallback to include guards instead of #pragma once (or use both). -- Summary: #pragma once is not exported from the precompiled headers Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bohan dot gnu at retropaganda dot info GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39029
Re: Attachments for gcc bugzilla entry #39028
2009/1/29 Stephan Springl springl-...@bfw-online.de: Hi, I just wanted to upload the attached files to gcc bugzilla entry #39028, but I always hit a bugzilla bug. Could you please attach these files to the bug for me? Well first patches go to gcc-patches@ list with a changelog. And then you don't need to upload them. Also try to login before attaching them. Thanks, Andrew Pinski
[Bug fortran/39030] New: Support -fexcess-precision={standard,fast} also for Fortran
From http://gcc.gnu.org/ml/fortran/2009-01/msg00332.html:
The C99 patch (for GCC 4.5),
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00105.html, fixes the excess
precision problem of the infamous PR 323 (yes, that old). For C99 there exists
a new option -fexcess-precision={standard,fast} which needs front end support.
-- PR 323 is especially about the x87 co-processor rounding, which is not IEEE
conform; work around is -ffloat-store or SSE.
The patch announcement came with Fixes bug 323 for C (other languages would
need their own front-end work to implement suitable predictable semantics under
the same command-line option in order to complete fixing the bug).
--
Summary: Support -fexcess-precision={standard,fast} also for
Fortran
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39030
[Bug target/39027] double floating point suffix of 'd' and 'D' not accepted
--- Comment #2 from janis at gcc dot gnu dot org 2009-01-29 21:20 --- In the C99 standard, floating constants are defined in section 6.4.4.2. A floating constant of type double is unsuffixed; there is no 'd' or 'D' suffix. Unless I'm missing something the test case is invalid. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39027
[Bug c/39026] Gcc accepts invalid code
--- Comment #4 from rguenther at suse dot de 2009-01-29 21:24 ---
Subject: Re: Gcc accepts invalid code
On Thu, 29 Jan 2009, joseph at codesourcery dot com wrote:
--- Comment #2 from joseph at codesourcery dot com 2009-01-29 20:02
---
Subject: Re: New: Gcc accepts invalid code
On Thu, 29 Jan 2009, hjl dot tools at gmail dot com wrote:
inline void foo ();
int
main ()
{
foo ();
return 0;
}
[...@gnu-6 gcc]$ gcc /tmp/i.i -S
If you use -std=c99 -pedantic-errors you get an error, as expected.
You're compiling in gnu89 mode.
If you use -std=c99 without -pedantic-errors you get a duplicate warning:
t.c:1: warning: inline function 'foo' declared but never defined
t.c:1: warning: inline function 'foo' declared but never defined
I think the frontend should, in C89 mode and if just issueing a warning,
set DECL_EXTERNAL properly on the decl.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39026
[Bug target/39027] double floating point suffix of 'd' and 'D' not accepted
--- Comment #3 from tydeman at tybor dot com 2009-01-29 21:52 --- The Decimal Floating-Point Technical Report (WG14/N1176 and later) added the suffixes 'd' and 'D' to indicate (binary) double, and 'dd' and 'DD' to indicate decimal double (_Decimal64). The suffixes 'd' and 'D' are in addition to unsuffixed decimal floating constants (all three mean 'double'). This is pages 12 and 13 in N1176, section 7 Constants, which is changing C99 section 6.4.4.2 floating-suffix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39027
[Bug target/39027] double floating point suffix of 'd' and 'D' not accepted
--- Comment #4 from janis at gcc dot gnu dot org 2009-01-29 21:57 --- We missed that. This is indeed a bug. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||bje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-29 21:57:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39027
[Bug fortran/38324] Wrong lbound given to allocatable components
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-29 22:03 --- patch http://gcc.gnu.org/ml/fortran/2009-01/msg00348.html The failure for ik=8 is not fixed by this patch. I thought it was ok because of the kind conversion function call. But it seems it's not. It is impacting function calls too (descriptor with wrong bounds passed), but the descriptor bounds are never used from within the function. This needs a bit more investigation. -- mikael at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38324
[Bug fortran/38956] test gfortran.dg/chmod_1.f90 fails on i686-pc-cygwin
--- Comment #3 from billingd at gcc dot gnu dot org 2009-01-29 22:09 --- I asked about this on the cygwin list. http://cygwin.com/ml/cygwin/2009-01/msg00718.html On Jan 24 18:40, David Billinghurst wrote: I am having a problem with the access() function in cygwin-1.7. Under cygwin-1.5 $ ./test_access access = -1 Under cygwin-1.7 $ ./test_access.exe access = -1 The reply was: I assume you mean access = 0 under 1.7. If that's what you see, the test probably works as designed. You're running the test under an administrative account. Admin accounts have always the right to write, same as under Linux. ... and my account has Local Administrator rights. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38956
[Bug fortran/38956] tests gfortran.dg/chmod_{1,2,3}.f90 fails on i686-pc-cygwin
--- Comment #4 from billingd at gcc dot gnu dot org 2009-01-29 22:14
---
Tests gfortran.dg/chmod_2.f90 and gfortran.dg/chmod_3.f90 also fail.
There is also some discussion at
http://gcc.gnu.org/ml/fortran/2009-01/msg00353.html
In each case, the failure is due to the test
i = chmod (n, a-w)
if (i == 0 .and. getuid() /= 0) then
if (access(n,w) == 0 .or. access(n,W) == 0) call abort
end if
The problem is that users with Administrator rights can always
write to files - similar to root on unix - but it is not easy to test for this.
I will prepare a patch that moves the parts that fail to a new test that is
UNSUPPORTED on cygwin.
--
billingd at gcc dot gnu dot org changed:
What|Removed |Added
Summary|test gfortran.dg/chmod_1.f90|tests
|fails on i686-pc-cygwin |gfortran.dg/chmod_{1,2,3}.f9
||0 fails on i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38956
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #43 from janis at gcc dot gnu dot org 2009-01-29 22:36 --- Rob, your various assertions do not show that there is a bug here. The failure of gcc.target/i386/funcspec-3.c described in comment #41 does not prove that the compiler under test is using GCC files from the install tree. I think it's either an intermittent failure or some problem with running the testsuite where you've already run them. In particular, that test doesn't appear to use any files that are in $(libdir)/gcc/, it's a compile-only test and cc1 is not in that part of the installation. The assertion in comment #37 that GCC_EXEC_PREFIX is simply always set is not true; it is only being set within the testsuite and from the Makefile as part of an invocation of runtest. The others don't make much sense, either. I built GCC from 20090106, broke a couple of thing affecting cc1, float.h, and libgcc.a, and installed it. Then I configured current mainline to use the same installation location, built it, and ran the tests affected the what I broke; they all passed. I added a test to print the value of GCC_EXEC_PREFIX and it confirmed that it was set. It does NOT affect the use of the compiler under test. Once again, the use of -B in the testsuite overrides GCC_EXEC_PREFIX for files that are part of GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug middle-end/39015] [4.3/4.4 regression] wrong code building libgsf
--- Comment #10 from doko at ubuntu dot com 2009-01-29 22:36 --- I'm able to reproduce it with trunk 20090129. The gsf-scan executable links against the just built libgsf.so, so I assume we have to look for a miscompiled file in libgsf. -- doko at ubuntu dot com changed: What|Removed |Added Known to fail|4.3.4 |4.3.4 4.4.0 Summary|[4.3 regression] wrong code |[4.3/4.4 regression] wrong |building libgsf |code building libgsf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug c++/38655] Broken diagnostic: 'fixed_point_type' not supported by dump_type_prefix/dump_type_suffix
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-29 22:38:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38655
[Bug middle-end/39015] [4.3/4.4 regression] wrong code building libgsf
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-01-29 22:39 --- I don't see anything in gsf-scan.c which would have been changed by that patch. All the arrays are already marked as static. The only ones that changed by that patch are auto arrays. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug middle-end/39015] [4.3/4.4 regression] wrong code building libgsf
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-01-29 22:41 --- (In reply to comment #9) Assuming there is a way to trigger this, I wonder if the program is legal. In particular I was looking at the initialization of GbArgTable which has a lot of holes in it. Those holes are all zero but the array GbArgTable is already declared as static so there will be no difference between before and after the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #27 from sezeroz at gmail dot com 2009-01-29 22:48 --- I can confirm that after applying pr_w64.diff of Kai Tietz to svn rev 143768, my similar problem which I reported at mingw-w64 site (which is also related to the 143119 commit) is fixed. Thanks to all who wonked on this. -- sezeroz at gmail dot com changed: What|Removed |Added CC||sezeroz at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
