Re: Small error in manual
* Ian Lance Taylor wrote on Wed, Mar 25, 2009 at 01:51:01AM CET:
Really the original text is slightly wrong.
[...]
This option only applies to strings in debugging information. It should
say something like Direct the linker to not merge together strings in
the debugging information which are identical in different object
files. Also I think s/It decreases/Merging decreases/.
OK with those changes.
Thanks, this is how I applied it (also s/assemblers or linker/s/)
after retesting.
Cheers,
Ralf
2009-03-25 Ralf Wildenhues ralf.wildenh...@gmx.de
* doc/invoke.texi (Debugging Options): Fix description of
-fno-merge-debug-strings.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 145050)
+++ gcc/doc/invoke.texi (working copy)
@@ -4408,11 +4408,11 @@
@item -fno-merge-debug-strings
@opindex fmerge-debug-strings
@opindex fno-merge-debug-strings
-Direct the linker to merge together strings which are identical in
-different object files. This is not supported by all assemblers or
-linker. This decreases the size of the debug information in the
-output file at the cost of increasing link processing time. This is
-on by default.
+Direct the linker to not merge together strings in the debugging
+information which are identical in different object files. Merging is
+not supported by all assemblers or linkers. Merging decreases the size
+of the debug information in the output file at the cost of increasing
+link processing time. Merging is enabled by default.
@item -fdebug-prefix-m...@var{old}=@var{new}
@opindex fdebug-prefix-map
[Bug tree-optimization/39355] [4.4 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL
--- Comment #49 from jakub at gcc dot gnu dot org 2009-03-25 07:30 --- Best is just to track where this VAR_DECL is being written into the pch file during PCH generation, see if it has DECL_HAS_VALUE_EXPR_P set, what DECL_VALUE_EXPR it has (if any) and if all is ok on that side, see during PCH reading whether DECL_HAS_VALUE_EXPR_P has been set and what went up with DECL_VALUE_EXPR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug tree-optimization/32139] [4.1 Regression] ICE in mark_operand_necessary
--- Comment #3 from uros at gcc dot gnu dot org 2009-03-25 07:59 --- Subject: Bug 32139 Author: uros Date: Wed Mar 25 07:58:55 2009 New Revision: 145052 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145052 Log: PR c/27898 * gcc.dg/pr27898.c: New test. PR tree-optimization/32139 * gcc.c-torture/compile/pr32139.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32139.c trunk/gcc/testsuite/gcc.dg/pr27898.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32139
[Bug c/27898] Compile failure with --combine and anonymous structures
--- Comment #6 from uros at gcc dot gnu dot org 2009-03-25 07:59 --- Subject: Bug 27898 Author: uros Date: Wed Mar 25 07:58:55 2009 New Revision: 145052 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145052 Log: PR c/27898 * gcc.dg/pr27898.c: New test. PR tree-optimization/32139 * gcc.c-torture/compile/pr32139.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32139.c trunk/gcc/testsuite/gcc.dg/pr27898.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27898
[Bug target/36654] [4.2 Regression] Inlined con/de-structor breaks virtual inheritance dllimport classes
--- Comment #12 from dave dot korn dot cygwin at gmail dot com 2009-03-25
08:03 ---
Hi all.
This patch caused g++.dg/ext/dllimport7.C to regress (in one subtest) between
4.3.2 and 4.3.3 on Cygwin, although it could be that the testcase is out of
date.
// { dg-do compile { target i?86-*-cygwin* i?86-*-mingw*} }
// Report errors on definition of dllimport'd static data member .
struct Baz
{
Baz(int a_ =0) : a(a_) {}
int a;
};
class __declspec(dllimport) Bar
{
public:
enum {one = 1};
static const int two = 2;
static const int three;
static const Baz null_baz;
};
const int Bar::three = 3; // { dg-warning redeclared without dllimport
}
// { dg-error definition of static data C++ specific error { target
i?86-*-cygwin* i?86-*-mingw* } 21 }
const Baz Bar::null_baz;// { dg-warning redeclared without dllimport
}
// { dg-error definition of static data C++ specific error { target
i?86-*-cygwin* i?86-*-mingw* } 24 }
int foo()
{
Bar foobar;
const int* baz = Bar::two;
int a = foobar.two;
int b = foobar.three;
int c = foobar.null_baz.a;
return (a + b + c + *baz);
}
Both the dg-error clauses now fail; previously (4.3.2), only the second one
failed. Reverting the patch causes the first dg-error (line 21) to pass again
by restoring the error message
/gnu/gcc/release/gcc4-4.3.3-1/src/gcc-4.3.3/gcc/testsuite/g++.dg/ext/dllimport7.
C:21: error: definition of static data member 'Bar::three' of dllimport'd class
I'm not sure why that should be a problem in the first place, so I don't know
if the underlying issue is now fixed and not an error any more. Anybody?
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed |Added
CC||dave dot korn dot cygwin at
||gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654
Register Allocation Bug?
Hi List I have a question (or possible compiler bug) regarding inline assembly that I hope you can help me with. I wanted a routine that would give me the value and address of a memory location relative to the stack pointer. What I initially tried was the following: #define ESP(rel,value,addr) \ asm volatile (mov (%%esp, %2, 4), %0\n\t \ lea (%%esp, %2, 4), %1\n\t \ : =r (value), =r (addr) \ : r (rel)); \ It didn't work as expected so I looked at the assembler code generated for the above: 1: b8 00 00 00 00 mov$0x0,%eax 2: 8b 04 84mov(%esp,%eax,4),%eax 3: 8d 14 84lea(%esp,%eax,4),%edx 4: 89 45 f8mov%eax,0xfff8(%ebp) 5: 89 55 fcmov%edx,0xfffc(%ebp) As it turns out, %eax is being used for both input and output in line 2, clobbering %eax, so of course line 3 does not give the expected result... Is this a compiler error? I thought the only way the same register would be used for both input and output was if you use the 0 constraint? I'm compiling with 'GCC 4.2.1 20070719'. The best solution I found was to split the two assembler statements in the following way: #define ESP(rel,value,addr) \ asm volatile (movl (%%esp, %1, 4), %0\n\t : \ =r (value) : r (rel));\ asm volatile (lea (%%esp, %1, 4), %0\n\t : \ =r (addr) : r (rel)); The above compiles into six instructions instead of five (duplicating mov $0x0,%eax) but is has the benefit of only using one register: 1: b8 00 00 00 00 mov$0x0,%eax 2: 8b 04 84mov(%esp,%eax,4),%eax 3: 89 45 fcmov%eax,0xfffc(%ebp) 4: b8 00 00 00 00 mov$0x0,%eax 5: 8d 04 84lea(%esp,%eax,4),%eax 6: 89 45 f0mov%eax,0xfff0(%ebp) So, again, my question is this: Is the compiler doing what it's supposed to when it's assigning the same register to both input and output when the specified constraint is r and not 0? As far as I can tell this problem have been floating around for a number of years. The following post from 2000 describes exactly the same issue: http://gcc.gnu.org/ml/gcc-bugs/2000-07/msg00456.html Since it hasn't been fixed maybe it's a bu..*ahem*..feature? Best /Kasper
[Bug middle-end/39497] dfp.c:239: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-03-25 12:00 --- Subject: Bug 39497 Author: rguenth Date: Wed Mar 25 12:00:32 2009 New Revision: 145057 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145057 Log: 2009-03-24 Richard Guenther rguent...@suse.de PR middle-end/39497 * Makefile.in (dfp.o-warn): Use -fno-strict-aliasing instead of -Wno-error. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39497
[Bug middle-end/39497] dfp.c:239: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-03-25 12:01 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39497
[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-25 12:12 --- Well, DECL_NO_TBAA_P is a hack and poorly implemented. Fallout expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39548
[Bug tree-optimization/39529] ICE on valid code
--- Comment #5 from irar at il dot ibm dot com 2009-03-25 12:27 --- Fixed. -- irar at il dot ibm dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39529
[Bug rtl-optimization/39543] [4.4 Regression] Reload failure on mplayer from SVN
--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-25 13:10 ---
That can be solved easily, just compare whether new_rtx doesn't need more
registers than old_rtx and only propagate into asm_noperands () = 0 insns
those that require the same number or fewer registers.
Consider e.g.:
int s[128];
void
f1 (void)
{
int i;
asm volatile (# %0 %1 %2 %3 %4 %5 %6 %7 %8 %9 %10 %11 %12 %13 %14 %15 %16
%17
: =r (i)
: m (s[0]), m (s[2]), m (s[4]), m (s[6]), m (s[8]),
m (s[10]), m (s[12]), m (s[14]), m (s[16]), m (s[18]),
m (s[20]), m (s[22]), m (s[24]), m (s[26]), m (s[28]),
m (s[30]), m (s[32]));
asm volatile (# %0 %1 %2 %3 %4 %5 %6 %7 %8 %9 %10 %11 %12 %13 %14 %15 %16
%17
: =r (i)
: m (s[0]), m (s[2]), m (s[4]), m (s[6]), m (s[8]),
m (s[10]), m (s[12]), m (s[14]), m (s[16]), m (s[18]),
m (s[20]), m (s[22]), m (s[24]), m (s[26]), m (s[28]),
m (s[30]), m (s[32]));
}
void
f2 (int *q)
{
int i;
int *p = q + 32;
asm volatile (# %0 %1 %2 %3 %4 %5 %6 %7 %8 %9 %10 %11 %12 %13 %14 %15 %16
%17
: =r (i)
: m (p[0]), m (p[2]), m (p[4]), m (p[6]), m (p[8]),
m (p[10]), m (p[12]), m (p[14]), m (p[16]), m (p[18]),
m (p[20]), m (p[22]), m (p[24]), m (p[26]), m (p[28]),
m (p[30]), m (p[32]));
asm volatile (# %0 %1 %2 %3 %4 %5 %6 %7 %8 %9 %10 %11 %12 %13 %14 %15 %16
%17
: =r (i)
: m (p[0]), m (p[2]), m (p[4]), m (p[6]), m (p[8]),
m (p[10]), m (p[12]), m (p[14]), m (p[16]), m (p[18]),
m (p[20]), m (p[22]), m (p[24]), m (p[26]), m (p[28]),
m (p[30]), m (p[32]));
}
at -O2, here cse_not_expected hack in stmt.c doesn't help, but I'd say fwprop
could fix it up.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39543
[Bug tree-optimization/28868] [4.2/4.3/4.4 Regression] Not eliminating the PHIs which have the same arguments
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-03-25 13:18 --- Re-confirmed. The fix is to eliminate duplicate PHI nodes in eliminate() by copy-propagating PHI value-numbers. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-02-04 10:14:52 |2009-03-25 13:18:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug target/39545] structures with zero-length array passed/returned inconsistently
--- Comment #5 from ubizjak at gmail dot com 2009-03-25 13:21 --- P1, so we won't forget to resolve this ABI issue before 4.4 branches. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2009-03-25 13:21:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39545
[Bug rtl-optimization/39543] [4.4 Regression] Reload failure on mplayer from SVN
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-25 15:49 --- Created an attachment (id=17540) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17540action=view) gcc44-pr39543.patch Untested patch that cures all the 3 testcases by forward propagation into asm operands, as long as the propagation doesn't increase the number of needed registers. As I need to update a bunch of locations at once, I can't use try_fwprop_subst. There are 2 things that try_fwprop_subst does that I'm not doing, one is the rtx_cost (SET_SRC (set), SET, speed) old_cost check (I wonder whether it is needed for asms at all and if yes, how to actually do it) and the update_df stuff (I'm never adding notes for asms, but for successful change I don't know how to inform df about the changes, if I need to do that. Paolo, any ideas? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39543
[Bug rtl-optimization/39543] [4.4 Regression] Reload failure on mplayer from SVN
--- Comment #7 from bonzini at gnu dot org 2009-03-25 16:49 --- one is the rtx_cost (SET_SRC (set), SET, speed) old_cost check (I wonder whether it is needed for asms at all and if yes, how to actually do it) For addresses it is already done in should_replace_address. But for everything else, there could be problems if one uses x = 0x123456789abcdef; and fwprop propagates x into the asm. If they used a r constraint (correctly), reload probably will fix everything, but it may cause pessimizations or I don't know what. Sorry for the handwaving---the reason I am a bit weary about propagating into asms is that we are quite careful about it on the tree level. pr39543-3.c crashes on f1 with optimization, but crashes on f2 without optimization. Which means that for f2, cse_not_expected does not work because gimplification effectively has already done the same as force_reg. In my opinion that's the root cause: we worry about making asms complex, but we're cavalier in making them simpler (hoping that something later restores the complexity). For 4.5, maybe SSA expansion fixes this? (pr39543-3.c in Jakub's patch). If so, modifying fwprop is probably not the best thing to do. -- bonzini at gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-25 16:49:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39543
[Bug target/39518] Missing documentation of cygwin and mingw target options
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-03-25 17:44 --- Committed at revision 145070. PR/39518 * doc/invoke.texi (-mconsole): New. (-mcygwin): New. (-mno-cygwin): New. (-mdll): New. (-mnop-fun-dllimport): New. (-mthread): New. (-mwin32): New. (-mwindows): New. (sub section i386 and x86-64 Windows Options): New. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39518
[Bug c++/39554] New: -Wdisallowed-function-list fails when #including algorithm
-Wdisallowed-function-list with any value fails when #including algorithm. Tested with SVN r145051: $ gcc -dumpversion 4.4.0 $ cat disallow_fault.cc #if OPT == 1 #include algorithm #endif $ g++ -DOPT=0 -c -Wdisallowed-function-list=BOGUS disallow_fault.cc $ g++ -DOPT=1 -c -Wdisallowed-function-list=BOGUS disallow_fault.cc In file included from /usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/bits/stl_pair.h:65, from /usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/bits/stl_algobase.h:71, from /usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/algorithm:66, from disallow_fault.cc:2: /usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/bits/move.h: In function void std::swap(_Tp ()[_Nm], _Tp ()[_Nm]): /usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/bits/move.h:98: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: -Wdisallowed-function-list fails when #including algorithm Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at gaul dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39554
[Bug fortran/39555] New: concat-op not allowed in STOP
The following is illegal (only digits or a character constant can follow STOP): $ cat stop.f90 STOP a // constant END $ gfortran-svn stop.f90 ./a.out STOP aconstant gcc version 4.4.0 20090324 (experimental) (GCC) -- Summary: concat-op not allowed in STOP Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39555
[Bug rtl-optimization/39543] [4.4 Regression] Reload failure on mplayer from SVN
--- Comment #8 from jakub at gcc dot gnu dot org 2009-03-25 18:31 --- fwprop won't propagate a constant into a r constrained asm operand, because verify_changes (0) fails in that case (it calls check_asm_operands, which verifies the constraints of all the operands). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39543
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #14 from prlw1 at cam dot ac dot uk 2009-03-25 18:57 --- I take it all is in hand, and I don't need to test anything? (I did a successful build with the same as the first patch, but defining _MACHINE_ANSI_H_ - this is equivalent - all went well) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug c++/39554] -Wdisallowed-function-list fails when #including algorithm
--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-25 19:45 ---
No need to include any header file:
// PR c++/39554
// { dg-do compile }
// { dg-options -Wdisallowed-function-list=bar }
void
foo (void (*p) ())
{
p ();
}
ICEs both in C and C++.
--
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|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-03-25 19:45:51
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39554
[Bug c++/39554] -Wdisallowed-function-list fails when #including algorithm
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-25 19:58 --- Created an attachment (id=17541) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17541action=view) gcc44-pr39554.patch Apparently no testing was done on this new feature at all :(. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39554
[Bug c/39556] New: statics in C99 inline functions later declared extern
C99 prohibits an inline definition of a function with external linkage
from containing modifiable static variables or references to file-scope
static variables or functions.
A definition is an inline definition only if all file-scope declarations
for the function in the translation unit use inline and do not use
extern. Thus, this cannot be determined until the end of the translation
unit. GCC gives the diagnostics for the above constraint too soon, leading
to the following valid examples being wrongly rejected with -std=c99
-pedantic-errors. It needs to defer them and see at the end of the
translation unit whether the definition is an inline definition after all.
Example 1:
static int a;
inline int f (void) { return a; }
int f (void);
Example 2:
inline void f (void) { static int a; }
extern inline void f (void);
--
Summary: statics in C99 inline functions later declared extern
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
OtherBugsDependingO 16989
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39556
[Bug rtl-optimization/39522] [4.4 Regression] fix for PR37514 gives FAIL: gcc.c-torture/execute/stdarg-3.c compilation, -O3 -fomit-frame-pointer -funroll-loops (internal compiler error)
--- Comment #3 from vmakarov at redhat dot com 2009-03-25 21:05 ---
Thanks for reporting this.
The compiler is broken on gcc_assert in the following code
+ else if ((code == PRE_INC || code == PRE_DEC
+ || code == POST_INC || code == POST_DEC))
+ {
+ int in_hard_regno;
+ int in_regno = REGNO (XEXP (in_reg, 0));
+
+ if (reg_last_reload_reg[in_regno] != NULL_RTX)
+ {
+ in_hard_regno = REGNO
(reg_last_reload_reg[in_regno]);
+ gcc_assert (TEST_HARD_REG_BIT (reg_reloaded_valid,
+in_hard_regno));
+ for (x = old_prev ? NEXT_INSN (old_prev) : insn;
+ x != old_next;
+ x = NEXT_INSN (x))
+ if (x == reg_reloaded_insn[in_hard_regno])
+ break;
+ /* If for some reasons, we didn't set up
+reg_last_reload_reg in this insn,
+invalidate inheritance from previous
+insns for the incremented/decremented
+register. Such registers will be not in
+reg_has_output_reload. */
+ if (x == old_next)
+ forget_old_reloads_1 (XEXP (in_reg, 0),
+ NULL_RTX, NULL);
+ }
+ }
Here in_regno is 191 and in_hard_regno is 8. This code is executed
after emit_insn_reloads which invalidates hard register 8 when
processing reload #5 of the current insn. I've overlooked this
possibility in my patch for PR37514
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01424.html
reg_reloaded_valid should be checked for reg_reloaded_insn validity
but not as gcc_assert. I'll send a new patch solving the problem soon.
(insn 411 1161 1160 17
/tmp/x144980/gcc/gcc/testsuite/gcc.c-torture/execute/stdarg-3.c:144 (set
(mem/s/c:SI (post_inc:SI (reg/f:SI 192)) [10 S4 A8])
(mem/s/c:SI (post_inc:SI (reg/f:SI 191)) [10 a3+4 S4 A16])) 38
{*movsi_internal} (expr_list:REG_INC (reg/f:SI 191)
(expr_list:REG_INC (reg/f:SI 192)
(nil
Reloads for insn # 411
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 14 sp)
(const_int 104 [0x68]))
GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0), can't combine
reload_in_reg: (plus:SI (reg/f:SI 14 sp)
(const_int 104 [0x68]))
reload_reg_rtx: (reg:SI 9 r9)
Reload 1: reload_in (SI) = (post_inc:SI (mem/c:SI (plus:SI (reg/f:SI 14 sp)
(const_int 104
[0x68])) [11 %sfp+-280 S4 A8]))
reload_out (SI) = (post_inc:SI (mem/c:SI (plus:SI (reg/f:SI 14 sp)
(const_int 104
[0x68])) [11 %sfp+-280 S4 A8]))
GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0), inc by 4, can't
combine
reload_in_reg: (post_inc:SI (reg/f:SI 192))
reload_reg_rtx: (reg:SI 6 r6)
Reload 2: reload_in (SI) = (plus:SI (reg/f:SI 14 sp)
(const_int 100 [0x64]))
GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1), can't combine
reload_in_reg: (plus:SI (reg/f:SI 14 sp)
(const_int 100 [0x64]))
reload_reg_rtx: (reg:SI 9 r9)
Reload 3: reload_in (SI) = (post_inc:SI (mem/c:SI (plus:SI (reg/f:SI 14 sp)
(const_int 100
[0x64])) [11 %sfp+-284 S4 A8]))
reload_out (SI) = (post_inc:SI (mem/c:SI (plus:SI (reg/f:SI 14 sp)
(const_int 100
[0x64])) [11 %sfp+-284 S4 A8]))
GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1), inc by 4, can't
combine
reload_in_reg: (post_inc:SI (reg/f:SI 191))
reload_reg_rtx: (reg:SI 8 r8)
Reload 4: reload_out (SI) = (mem/s/c:SI (post_inc:SI (reg/f:SI 192)) [10 S4
A8])
NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (mem/s/c:SI (post_inc:SI (reg/f:SI 192)) [10 S4 A8])
Reload 5: reload_in (SI) = (mem/s/c:SI (post_inc:SI (reg/f:SI 191)) [10 a3+4 S4
A16])
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (mem/s/c:SI (post_inc:SI (reg/f:SI 191)) [10 a3+4 S4
A16])
reload_reg_rtx: (reg:SI 8 r8)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39522
[Bug c++/34691] [4.2/4.3/4.4 Regression] Default argument checking not performed after overload resolution with C linkage
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-01-06 20:54:23 |2009-03-25 21:10:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34691
[Bug target/39085] Floating point errors on Arm9 processor
--- Comment #6 from rearnsha at gcc dot gnu dot org 2009-03-25 21:54
---
(In reply to comment #2)
str r3, [fp, #-32]
str r4, [fp, #-28]
ldfd f0, [fp, #-32]
sqtd f0, f0
stfd f0, [fp, #-40]
ldfd f0, [fp, #-40]
ldfd f0, [fp, #-40]
cmf f0, f0
beq .L2
sub r0, fp, #32
ldmia r0, {r0-r1}
blsqrt
stfd f0, [fp, #-40]
You need to understand what this code is doing to work out the source of the
bug. The compiler is inlining a copy of the square-root function with an FPA
co-processor instruction
sqtd f0, f0
which, if successful will replace the library call. If the square root
succeeds it will not return a NaN, so the comparison of the result
cmf f0, f0
will be that the two results are equal (a NaN never compares equal to itself).
So the square root function (sqrt) will only be called if a NaN was generated
by the machine instruction; it does this in order to set errno.
Of course, the ARM9 does not have an FPA co-processor so the original sqtd
instruction will be emulated by your operating system -- I strongly suspect
that that is what is generating the incorrect results and you now need to
investigate why.
If you still believe the bug is in the compiler you need to provide some
additional information, including how you configured the compiler and what
options you used when compiling your code.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu dot
||org
Status|WAITING |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39085
[Bug target/39175] ICE while compiling qt-4.5.0-rc1
--- Comment #7 from bje at gcc dot gnu dot org 2009-03-25 22:05 --- Subject: Bug 39175 Author: bje Date: Wed Mar 25 22:05:08 2009 New Revision: 145076 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145076 Log: Backport from mainline: 2009-02-19 Jakub Jelinek ja...@redhat.com PR target/39175 * c-common.c (c_determine_visibility): If visibility changed and DECL_RTL has been already set, call make_decl_rtl to update symbol flags. cp/ * decl2.c (determine_visibility): If visibility changed and DECL_RTL has been already set, call make_decl_rtl to update symbol flags. testsuite/ * gcc.dg/visibility-20.c: New test. * g++.dg/ext/visibility/visibility-11.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/visibility/visibility-11.C branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/visibility-20.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-common.c branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/decl2.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39175
[Bug target/39175] ICE while compiling qt-4.5.0-rc1
--- Comment #8 from bje at gcc dot gnu dot org 2009-03-25 22:06 --- Now fixed on the 4.3 branch and on mainline. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39175
[Bug target/39175] ICE while compiling qt-4.5.0-rc1
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39175
[Bug target/39523] [4.4 Regression] SH: global registers are wrongly saved
--- Comment #1 from kkojima at gcc dot gnu dot org 2009-03-25 22:23 --- Subject: Bug 39523 Author: kkojima Date: Wed Mar 25 22:23:27 2009 New Revision: 145077 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145077 Log: PR target/39523 * config/sh/sh.c (calc_live_regs): Fix condition for global registers except PIC_OFFSET_TABLE_REGNUM. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39523
[Bug target/39523] [4.4 Regression] SH: global registers are wrongly saved
--- Comment #2 from kkojima at gcc dot gnu dot org 2009-03-25 22:26 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39523
[Bug tree-optimization/39557] New: Invalid PDOM lead to infinite loop to be generated
Compiling the attached source with the following options -Wall -fno-exceptions -O2 -fprofile-use=/blah -fno-rtti will result in a code with infinite loop. In DCE, special code is added to handle dead loops conservatively. However this requires PDOM information (control dep info) to be valid. The PDOM is created in unintialized variable warning, but gets invalidated before cddce pass (the incremental update does not work well). With the wrong CD info, DCE pass tries to eliminate the loop, but the exit edge fixup code ends up linking the precessor not to its post-dom bb, but to itself -- leading to infinite loop. A proposed patch will be posted to gcc-patches. David -- Summary: Invalid PDOM lead to infinite loop to be generated Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: davidxl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39557
[Bug tree-optimization/39557] Invalid PDOM lead to infinite loop to be generated
--- Comment #1 from davidxl at gcc dot gnu dot org 2009-03-25 23:10 --- Created an attachment (id=17542) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17542action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39557
[Bug target/39558] New: Fortran iresolve.c cannot be built with -maltivec used in bootstrap
Adding -maltivec to the PowerPC compiler turns on the altivec vector support.
Part of the vector support is to add conditional expansion of the vector
keyword if it looks like vector is part of a type declaration (i.e. vector
float would declare a single precision floating point 4 element vector, or
V4SF). If the next thing after vector is a macro that expands to
__attribute__((__unused__)), the compiler will realize that it should expand
vector to vector, and then glue it with the __attribute__. I discovered this
when doing a bootstrap of the compiler with the power7 VSX instructions enabled
(VSX includes Altivec).
This is the declaration in fortran/iresolve.c that shows the problem:
void
gfc_resolve_pack (gfc_expr *f, gfc_expr *array, gfc_expr *mask,
gfc_expr *vector ATTRIBUTE_UNUSED)
{
/* ... */
}
If we change the argument to something other than vector, it will allow the
code to be compiled with -maltivec, but the underlying problem should be fixed.
--
Summary: Fortran iresolve.c cannot be built with -maltivec used
in bootstrap
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meissner at linux dot vnet dot ibm dot com
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Fortran iresolve.c cannot be built with -maltivec used in bootstrap
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-03-25 23:24 --- Created an attachment (id=17543) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17543action=view) Simplified test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Fortran iresolve.c cannot be built with -maltivec used in bootstrap
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-25 23:51:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug preprocessor/39559] New: constants too large for intmax_t need pedwarns
unsigned long long l = 9223372036854775808LL; should get an error with -std=c99 -pedantic-errors, but instead gets a warning: t.c:1:24: warning: integer constant is so large that it is unsigned C99 does not allow decimal constants without U suffix to get an unsigned type. I think the preprocessor should pedwarn in this case (for C99, not C90), to catch the use of such constants in #if conditions as well. The preprocessor already pedwarns for a value large enough to be outside the range of uintmax_t (which is used to set the preprocessor's internal precision), so I believe this case of a constant inside the range of uintmax_t but outside that of intmax_t, in decimal without U suffix, is the only current case of this bug. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934#c15 for some historical discussion (but it doesn't appear types wider than intmax_t can ever appear this way after all). -- Summary: constants too large for intmax_t need pedwarns Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org OtherBugsDependingO 16989 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39559
[Bug rtl-optimization/39522] [4.4 Regression] fix for PR37514 gives FAIL: gcc.c-torture/execute/stdarg-3.c compilation, -O3 -fomit-frame-pointer -funroll-loops (internal compiler error)
--- Comment #4 from hp at gcc dot gnu dot org 2009-03-26 01:34 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01229.html. Thanks! I'll test crisv32-axis-linux-gnu and report. -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2009-03-26 01:34:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39522
[Bug c/37595] funcs.c:323: internal compiler error: Segmentation fault
--- Comment #2 from bje at gcc dot gnu dot org 2009-03-26 04:28 --- Can you check this with GCC 4.3.3 (or the tip of the GCC 4.3 branch), please? I cannot reproduce this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37595
[Bug target/25160] ICE in print_operand if using -mfloat-gprs w/ non-854x -mcpu option
--- Comment #1 from bje at gcc dot gnu dot org 2009-03-26 04:32 --- I think this patch should suffice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25160
[Bug c++/39560] New: Erroneous wanings 'unused variable' in a templetated class method with union
This testcase has warnings:
--- begin testcase ---
struct X { };
class Z {
public:
X* cc(int c);
};
class F {
public:
typedef X* (Z::*MethO)(int);
typedef X* (F::*MethF)(int);
templateMethO m
X* xwrapper(int i) {
union {
Z *z;
F *f;
};
f = this;
return ((z-*m)(i));
}
};
F::MethF meth = F::xwrapperZ::cc;
--- end testcase ---
warnings:
c.C: In member function X* F::xwrapper(int) [with X* (Z::* m)(int) = Z::cc]:
c.C:23: instantiated from here
c.C:17: warning: unused variable z
c.C:17: warning: unused variable f
--
Summary: Erroneous wanings 'unused variable' in a templetated
class method with union
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39560
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
-- bje at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bje at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-03-25 23:51:35 |2009-03-26 05:06:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
