[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support

[bje at gcc dot gnu dot org]

-- 

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

[Bug c++/39560] New: Erroneous wanings 'unused variable' in a templetated class method with union

[yuri at tsoft dot com]

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);
  template
  X* xwrapper(int i) {
union {
  Z *z;
  F *f;
};
f = this;
return ((z->*m)(i));
  }
};

F::MethF meth = &F::xwrapper<&Z::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/25160] ICE in print_operand if using -mfloat-gprs w/ non-854x -mcpu option

[bje at gcc dot gnu dot org]

--- 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/37595] funcs.c:323: internal compiler error: Segmentation fault

[bje at gcc dot gnu dot org]

--- 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 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)

[hp at gcc dot gnu dot org]

--- Comment #4 from hp at gcc dot gnu dot org  2009-03-26 01:34 ---
Patch at .
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 preprocessor/39559] New: constants too large for intmax_t need pedwarns

[jsm28 at gcc dot gnu dot org]

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  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 target/39558] Fortran iresolve.c cannot be built with -maltivec used in bootstrap

[steven at gcc dot gnu dot org]

-- 

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 target/39558] Fortran iresolve.c cannot be built with -maltivec used in bootstrap

[meissner at linux dot vnet dot ibm dot com]

--- 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=17543&action=view)
Simplified test case


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558

[Bug target/39558] New: Fortran iresolve.c cannot be built with -maltivec used in bootstrap

[meissner at linux dot vnet dot ibm dot com]

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 tree-optimization/39557] Invalid PDOM lead to infinite loop to be generated

[davidxl at gcc dot gnu dot org]

--- 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=17542&action=view)
test case


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39557

[Bug tree-optimization/39557] New: Invalid PDOM lead to infinite loop to be generated

[davidxl at gcc dot gnu dot org]

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 target/39523] [4.4 Regression] SH: global registers are wrongly saved

[kkojima at gcc dot gnu dot org]

--- 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 target/39523] [4.4 Regression] SH: global registers are wrongly saved

[kkojima at gcc dot gnu dot org]

--- 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=gcc&view=rev&rev=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/39175] ICE while compiling qt-4.5.0-rc1

[rguenth at gcc dot gnu dot org]

-- 

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/39175] ICE while compiling qt-4.5.0-rc1

[bje at gcc dot gnu dot org]

--- 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

[bje at gcc dot gnu dot org]

--- 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=gcc&view=rev&rev=145076
Log:
Backport from mainline:
2009-02-19  Jakub Jelinek  

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/39085] Floating point errors on Arm9 processor

[rearnsha at gcc dot gnu dot org]

--- 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 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]

-- 

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 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)

[vmakarov at redhat dot com]

--- 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/39556] New: statics in C99 inline functions later declared extern

[jsm28 at gcc dot gnu dot org]

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 c++/39554] -Wdisallowed-function-list fails when #including

[jakub at gcc dot gnu dot org]

--- 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=17541&action=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++/39554] -Wdisallowed-function-list fails when #including

[jakub at gcc dot gnu dot org]

--- 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 target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_

[prlw1 at cam dot ac dot uk]

--- 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 rtl-optimization/39543] [4.4 Regression] Reload failure on mplayer from SVN

[jakub at gcc dot gnu dot org]

--- 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 fortran/39555] New: concat-op not allowed in STOP

[dfranke at gcc dot gnu dot org]

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 c++/39554] New: -Wdisallowed-function-list fails when #including

[gcc at gaul dot org]

-Wdisallowed-function-list with any value fails when #including . 
Tested with SVN r145051:

$ gcc -dumpversion
4.4.0

$ cat disallow_fault.cc 
#if OPT == 1
#include 
#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  for instructions.


-- 
   Summary: -Wdisallowed-function-list fails when #including

   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 target/39518] Missing documentation of cygwin and mingw target options

[ktietz at gcc dot gnu dot org]

--- 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 rtl-optimization/39543] [4.4 Regression] Reload failure on mplayer from SVN

[bonzini at gnu dot org]

--- 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 rtl-optimization/39543] [4.4 Regression] Reload failure on mplayer from SVN

[jakub at gcc dot gnu dot org]

--- 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=17540&action=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 target/39545] structures with zero-length array passed/returned inconsistently

[ubizjak at gmail dot com]

--- 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 tree-optimization/28868] [4.2/4.3/4.4 Regression] Not eliminating the PHIs which have the same arguments

[rguenth at gcc dot gnu dot org]

--- 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 rtl-optimization/39543] [4.4 Regression] Reload failure on mplayer from SVN

[jakub at gcc dot gnu dot org]

--- 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/39529] ICE on valid code

[irar at il dot ibm dot com]

--- 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 tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate

[rguenth at gcc dot gnu dot org]

--- 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 middle-end/39497] dfp.c:239: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules

[rguenth at gcc dot gnu dot org]

--- 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 middle-end/39497] dfp.c:239: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules

[rguenth at gcc dot gnu dot org]

--- 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=gcc&view=rev&rev=145057
Log:
2009-03-24  Richard Guenther  

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

Register Allocation Bug?

[Kasper Bonne]

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 target/36654] [4.2 Regression] Inlined con/de-structor breaks virtual inheritance dllimport classes

[dave dot korn dot cygwin at gmail dot com]

--- 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

[Bug c/27898] Compile failure with --combine and anonymous structures

[uros at gcc dot gnu dot org]

--- 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=gcc&view=rev&rev=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 tree-optimization/32139] [4.1 Regression] ICE in mark_operand_necessary

[uros at gcc dot gnu dot org]

--- 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=gcc&view=rev&rev=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 tree-optimization/39355] [4.4 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL

[jakub at gcc dot gnu dot org]

--- 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