[Bug fortran/44773] [4.6 Regression] Unnecessary temporaries increase the runtime for channel.f90 by ~70%

[steven at gcc dot gnu dot org]

--- Comment #21 from steven at gcc dot gnu dot org  2010-07-12 07:26 ---
I think this should not go into GCC 4.3 anyway. The problem is not a
regression, and the patch is non-obvious, so it's just not appropriate for a
stable release branch.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/37077] Implement Internal Unit I/O for character KIND=4

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2010-07-12 07:54 ---
Patch: http://gcc.gnu.org/ml/fortran/2010-07/msg00113.html


-- 


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

[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2010-07-12 07:54 
---
It indeed works with the 4.5.0 release which makes it a blocker for 4.5.1.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug c++/44916] New: Incorrect function overloading with static_cast

[ian at airs dot com]

When I compile this test case with mainline c++:

struct S {};
struct T : S {};
int f(const T*) {}
void f(T*);
int main() {
  S* s(0);
  int a = f(static_cast(s));
  int b = f(static_cast(0));
}

I get this:

foo.cc: In function ‘int main()’:
foo.cc:7:37: error: void value not ignored as it ought to be

This seems wrong.  I'm casting the value, so it should pick up the overload
which returns an int.  Note in particular that it works when casting 0 but
fails when casting a real object.


-- 
   Summary: Incorrect function overloading with static_cast
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com


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

[Bug tree-optimization/44915] [4.6 Regression] ICE: SIGSEGV in walk_aliased_vdefs_1.constprop.42 (tree-ssa-alias.c:1707) with -findirect-inlining

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.6.0


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

[Bug tree-optimization/44914] [4.6 Regression] ICE: in calc_dfs_tree, at dominance.c:395 with -fipa-sra -fnon-call-exceptions

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

[rguenth at gcc dot gnu dot org]

--- Comment #55 from rguenth at gcc dot gnu dot org  2010-07-12 08:06 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libfortran/35862] [F2003] Implement new rounding modes for run time

[burnus at gcc dot gnu dot org]

--- Comment #22 from burnus at gcc dot gnu dot org  2010-07-12 08:07 ---
Implemented: Rounding on output.

TODO: Rounding on input. Current result for the program below is:

0.1000149011611938E+00
0.1000149011611938E+00
0.1555E+00
0.1555E+00

Expected:
0.1000149011611938E+00
0.9882280826568604E-01
0.1555E+00
0.99783507E-01

(i.e. '"round up" == "round down" + epsilon(r)')

(Side remark: None of my tested compiles handles this; not gfortran, not ifort
nor crayftn.)

Test program:

character(len=5) :: str
real(4) :: r4_1, r4_2
real(8) :: r8_1, r8_2

str = "0.1"
read(str,'(ru,g3.1)') r4_1
read(str,'(rd,g3.1)') r4_2
read(str,'(ru,g3.1)') r8_1
read(str,'(rd,g3.1)') r8_2
print '(e30.20)', r4_1
print '(e30.20)', r4_2
print '(e30.20)', r8_1
print '(e30.20)', r8_2
end


-- 


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

[Bug fortran/44917] New: [OOP] Detect ambiguous specifics in a generic TBP interface

[janus at gcc dot gnu dot org]

The current form of the test case dynamic_dispatch_1.f03 is illegal:


module m
  type :: t1
integer :: i = 42
procedure(make_real), pointer :: ptr
  contains
procedure, pass :: real => make_real
procedure, pass :: make_integer
procedure, pass :: prod => i_m_j
generic, public :: extract => real, make_integer
generic, public :: base_extract => real, make_integer
  end type t1

  type, extends(t1) :: t2
integer :: j = 99
  contains
procedure, pass :: real => make_real2
procedure, pass :: make_integer_2
procedure, pass :: prod => i_m_j_2
generic, public :: extract => real, make_integer_2
  end type t2
contains
  real function make_real (arg)
class(t1), intent(in) :: arg
make_real = real (arg%i)
  end function make_real

  real function make_real2 (arg)
class(t2), intent(in) :: arg
make_real2 = real (arg%j)
  end function make_real2

  integer function make_integer (arg, arg2)
class(t1), intent(in) :: arg
integer :: arg2
make_integer = arg%i * arg2
  end function make_integer

  integer function make_integer_2 (arg, arg2)
class(t2), intent(in) :: arg
integer :: arg2
make_integer_2 = arg%j * arg2
  end function make_integer_2

  integer function i_m_j (arg)
class(t1), intent(in) :: arg
i_m_j = arg%i
  end function i_m_j

  integer function i_m_j_2 (arg)
class(t2), intent(in) :: arg
i_m_j_2 = arg%j
  end function i_m_j_2
end module m


It is rejected by the NAG compiler with:

Error: dynamic_dispatch_1.f03, line 58: Ambiguous specific type-bound
procedures MAKE_INTEGER_2 and MAKE_INTEGER for type-bound generic EXTRACT in
type T2

gfortran currently fails to detect that.


-- 
   Summary: [OOP] Detect ambiguous specifics in a generic TBP
interface
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org


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

[Bug fortran/44917] [OOP] Detect ambiguous specifics in a generic TBP interface

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2010-07-12 08:59 ---
Reduced version:

module m

  type :: t1
integer :: i = 42
  contains
procedure, pass :: make_integer
generic, public :: extract => make_integer
  end type t1

  type, extends(t1) :: t2
integer :: j = 99
  contains
procedure, pass :: make_integer_2
generic, public :: extract => make_integer_2
  end type t2

contains

  integer function make_integer (arg, arg2)
class(t1), intent(in) :: arg
integer :: arg2
make_integer = arg%i * arg2
  end function make_integer

  integer function make_integer_2 (arg, arg2)
class(t2), intent(in) :: arg
integer :: arg2
make_integer_2 = arg%j * arg2
  end function make_integer_2

end module m



-- 


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

[Bug fortran/44917] [OOP] Detect ambiguous specifics in a generic TBP interface

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2010-07-12 09:02 ---
Note that the ambiguity is detected if both specifics are already defined in
the base class:

module m

  type :: t1
integer :: i = 42
  contains
procedure, pass :: make_integer
procedure, pass :: make_integer_2
generic, public :: extract => make_integer, make_integer_2
  end type t1

contains

  integer function make_integer (arg, arg2)
class(t1), intent(in) :: arg
integer :: arg2
make_integer = arg%i * arg2
  end function make_integer

  integer function make_integer_2 (arg, arg2)
class(t1), intent(in) :: arg
integer :: arg2
make_integer_2 = arg%i * arg2**2
  end function make_integer_2

end module m



generic, public :: extract => make_integer, make_integer_2
 1
Error: 'make_integer' and 'make_integer_2' for GENERIC 'extract' at (1) are
ambiguous


-- 


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

[Bug c/44918] New: Calculation on y = x++ + x++ depends on following statements

[eric dot liu at uniquesoft dot com]

#include 

void UnspecifiedSideEffectInExpression(int c)
{
int x = 0, y = 0, z = 20, t = 30, *p, *q;

x = c;
y = x++ + x++;
printf("x = %d, y = %d\n", x, y);

//Comment out the following code to get a different result
p = (c&2) ? &x : &t;
printf("*p = %d\n", *p);

}

int main()
{
UnspecifiedSideEffectInExpression(1);

return 0;
}


-- 
   Summary: Calculation on y = x++ + x++ depends on following
statements
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot liu at uniquesoft dot com


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

[Bug c/44918] Calculation on y = x++ + x++ depends on following statements

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-07-12 09:19 ---
There is no sequence point between the two modifications to x.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   GCC host triplet|CentOS 5.3 on i386  |
 Resolution||INVALID


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

[Bug c/44918] Calculation on y = x++ + x++ depends on following statements

[eric dot liu at uniquesoft dot com]

--- Comment #2 from eric dot liu at uniquesoft dot com  2010-07-12 09:34 
---
I don't understand what is sequence point.
But as a user, I DO want gcc to produce the same result.
As for the code in the bug description, the result is:
x = 2, y = 2
*p = 30

If comment out the code indicated in the bug description, the result is
x = 3, y = 2

The result is different. Why?


-- 


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

[Bug target/44888] Stack pointer corruption within interrupt routine when compiled with -Os

[ramana at gcc dot gnu dot org]

--- Comment #1 from ramana at gcc dot gnu dot org  2010-07-12 09:35 ---
Confirmed - I think it should be fixed by this patch here. 

http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00495.html

Jie : do you think you could backport this to the 4.5 branch ? 

cheers
Ramana


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jiez at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.5.0
  Known to work||4.4.4 4.6.0
   Last reconfirmed|-00-00 00:00:00 |2010-07-12 09:35:45
   date||


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

[Bug target/44860] Thumb ICE due to spill failure

[ramana at gcc dot gnu dot org]

--- Comment #2 from ramana at gcc dot gnu dot org  2010-07-12 09:43 ---

Confirmed with Thumb1. 

Just to be clear - command line options that cause the crash are :

 ./xgcc -B`pwd` -S -Os -mthumb -fno-omit-frame-pointer /tmp/t2ice.c 
-march=armv5te
/tmp/t2ice.c: In function '__libc_recvfrom':
/tmp/t2ice.c:5:7: error: unable to find a register to spill in class 'LO_REGS'
/tmp/t2ice.c:5:7: error: this is the insn:
(insn 73 19 74 2 /tmp/t2ice.c:5 (set (reg:SI 12 ip [150])
(const_int 146 [0x92])) 167 {*thumb1_movsi_insn} (expr_list:REG_EQUAL
(const_int 146 [0x92])
(nil)))
/tmp/t2ice.c:5: confused by earlier errors, bailing out


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.5.0
   Last reconfirmed|-00-00 00:00:00 |2010-07-12 09:43:13
   date||


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

[Bug c/44918] Calculation on y = x++ + x++ depends on following statements

[eric dot liu at uniquesoft dot com]

--- Comment #3 from eric dot liu at uniquesoft dot com  2010-07-12 09:49 
---
Refer to my previous comment, I need to reopen it for a correct answer.


-- 

eric dot liu at uniquesoft dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c/44918] Calculation on y = x++ + x++ depends on following statements

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2010-07-12 09:54 ---
The correct answer is: "here is no sequence point between the two modifications
to x.".

If you don't know what a sequence point is, use Google (see first hit,
Wikipedia).
If you don't know C, don't use C.
And don't reopen bugs because you're too bloody lazy to do any searching
yourself.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/44888] Stack pointer corruption within interrupt routine when compiled with -Os

[jiez at gcc dot gnu dot org]

--- Comment #2 from jiez at gcc dot gnu dot org  2010-07-12 09:57 ---
Ramana, I will do it.


-- 


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

[Bug debug/44901] [4.6 Regression] -fcompare-debug failure for tree-predcom.c

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-07-12 10:19 ---
Fails even with -fno-var-tracking, so does not look VTA related.


-- 


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

[Bug c++/44808] [4.6 Regression] ICE: tree check: expected var_decl, have result_decl in gimplify_modify_expr

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-07-12 10:38 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug pch/14940] PCH largefile test fails on various platforms

[ro at gcc dot gnu dot org]

--- Comment #40 from ro at gcc dot gnu dot org  2010-07-12 11:57 ---
Subject: Bug 14940

Author: ro
Date: Mon Jul 12 11:57:16 2010
New Revision: 162074

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162074
Log:
PR pch/14940
* config/host-solaris.c (mmap_fixed): New function.
(sol_gt_pch_get_address): Use it.
(sol_gt_pch_use_address): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/host-solaris.c


-- 


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

[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail

[iains at gcc dot gnu dot org]

--- Comment #10 from iains at gcc dot gnu dot org  2010-07-12 12:54 ---
(In reply to comment #9)
> (In reply to comment #8)
> > Perhaps we just need something like...

> In the native boostrap case, you probably want
> CC_FOR_TARGET / CFLAGS_FOR_TARGET / CXX_FOR_TARGET / CXXFLAGS_FOR_TARGET,
> but you still need COMPILER COMPILER_FLAGS (or its equivalent) in the
> case of non-bootstrap builds (native or otherwise).

since the plugin is to run on the host, looking at the top level makefile
HOST_EXPORTS defines CC - so, as you say, the current settings in gcc/Makefile
are honoring that.  However, it's clear that CC is ending up set to the
bootstrap compiler and not the one built for stage2/3.  I wonder if that means
that HOST_EXPORTS needs to be re-written for each stage.. 

Is there any cross-tool known to support plugins? (I get no response for
cris-elf, s390x, mipsia64 and armel-linux-gnueabi).  No error, just silently
skips all plugin tests.

Or is there a requirement that the host compiler is >= some gcc version in that
case?


-- 

iains at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||iains at gcc dot gnu dot org


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

[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail

[howarth at nitro dot med dot uc dot edu]

--- Comment #11 from howarth at nitro dot med dot uc dot edu  2010-07-12 
13:05 ---
I wonder if there is any overlap with this bug and PR29404/42308?


-- 


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

[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail

[iains at gcc dot gnu dot org]

--- Comment #12 from iains at gcc dot gnu dot org  2010-07-12 13:19 ---
(In reply to comment #10)

> Is there any cross-tool known to support plugins? (I get no response for
> cris-elf, s390x, mipsia64 and armel-linux-gnueabi).  No error, just silently
> skips all plugin tests.

hmm this is a configury/make issue (possibly darwin-specific), 
I suspect that the switch changes to deal with linker attributes are being
driven on target keys and not on host ones.


-- 


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

[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail

[iains at gcc dot gnu dot org]

--- Comment #13 from iains at gcc dot gnu dot org  2010-07-12 13:28 ---
(In reply to comment #12)
> (In reply to comment #10)
> 
> > Is there any cross-tool known to support plugins? (I get no response for
> > cris-elf, s390x, mipsia64 and armel-linux-gnueabi).  No error, just silently
> > skips all plugin tests.
> 
> hmm this is a configury/make issue (possibly darwin-specific), 
> I suspect that the switch changes to deal with linker attributes are being
> driven on target keys and not on host ones.

 nope, not that :

  case "${host}" in
*-*-darwin*)
  CFLAGS=`echo $CFLAGS | sed s/-mdynamic-no-pic//g` <== a local change I
made for powerpc.
  CFLAGS="$CFLAGS -fPIC"
  LDFLAGS="$LDFLAGS -shared -undefined dynamic_lookup"
;;
*)
  CFLAGS="$CFLAGS -fPIC"
  LDFLAGS="$LDFLAGS -fPIC -shared"
;;
  esac

I'll have to check the config.log more carefully.


-- 


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

[Bug c/32511] [4.4/4.5/4.6 regression] GCC rejects inline+weak function

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2010-07-12 13:46 ---
Marking as regression.  Weak symbols have multiple uses: allowing replacement
is one, but they are also used to allow equivalent definitions in multiple
translation units without linker errors.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|accepts-invalid, wrong-code |rejects-valid
Summary|GCC inlines weak function   |[4.4/4.5/4.6 regression] GCC
   ||rejects inline+weak function


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

[Bug target/44888] Stack pointer corruption within interrupt routine when compiled with -Os

[jiez at gcc dot gnu dot org]

--- Comment #3 from jiez at gcc dot gnu dot org  2010-07-12 14:06 ---
My patch has been committed on trunk and 4.5 branch. This bug should be fixed
now. Please verify.


-- 


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

[Bug target/44888] Stack pointer corruption within interrupt routine when compiled with -Os

[jiez at gcc dot gnu dot org]

--- Comment #4 from jiez at gcc dot gnu dot org  2010-07-12 14:07 ---
The updated patch:

http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00968.html


-- 


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

[Bug debug/44901] [4.6 Regression] -fcompare-debug failure for tree-predcom.c

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-07-12 14:26 ---
Created an attachment (id=21183)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21183&action=view)
pr44901.i

Reduced testcase:

./xgcc -B ./ -S -m32 -fcompare-debug -O2 -fno-var-tracking /tmp/pr44901.i -w
xgcc: error: /tmp/pr44901.i: -fcompare-debug failure


-- 


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

[Bug debug/44901] [4.6 Regression] -fcompare-debug failure for tree-predcom.c

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-07-12 14:50 ---
All the unordered removals for local_decls are obviously wrong.


-- 


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

[Bug debug/44901] [4.6 Regression] -fcompare-debug failure for tree-predcom.c

[froydnj at codesourcery dot com]

--- Comment #6 from froydnj at codesourcery dot com  2010-07-12 14:56 
---
Subject: Re:  [4.6 Regression] -fcompare-debug failure for
tree-predcom.c

Why are the unordered removals "obviously" wrong?  And why, if they're
"obviously" wrong, does this problem only turn up with a specific
bootstrap config?


-- 


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

[Bug fortran/42385] [OOP] poylmorphic operators do not work

[sfilippone at uniroma2 dot it]

--- Comment #2 from sfilippone at uniroma2 dot it  2010-07-12 14:58 ---
(In reply to comment #1)
Hi Damian,
This is related to the original test case for PR 43945; that test case is now
going to handle the dynamic side of it, but the problem with generics exists
with normal typebound procedures as well. It seems to be related to the
binding_name => specific_name thing, operators are not really relevant. 


-- 


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

[Bug fortran/42385] [OOP] poylmorphic operators do not work

[sfilippone at uniroma2 dot it]

--- Comment #3 from sfilippone at uniroma2 dot it  2010-07-12 14:59 ---
Created an attachment (id=21184)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21184&action=view)
additional test-case


-- 


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

[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail

[iains at gcc dot gnu dot org]

--- Comment #14 from iains at gcc dot gnu dot org  2010-07-12 15:00 ---
(In reply to comment #13)

> I'll have to check the config.log more carefully.

OK. possible a can of wiggly things here... 

  case "${host}" in
*-*-darwin*)
  export_sym_check="$gcc_cv_nm -g"  <=== maybe these need to be $NM 
;;
*)
  export_sym_check="$gcc_cv_objdump -T"  < ... and $OBJDUMP in any
event, the correct host tool
;;
  esac

looks fine - until you find that gcc_cv_nm is being set to
 ../binutils/nm   == nm-for-target
when host==build (and we've built the tool).

AS_VAR_SET_IF(gcc_cv_nm,, [
if test -f $gcc_cv_binutils_srcdir/configure.in \
 && test -f ../binutils/Makefile \
 && test x$build = x$host; then
gcc_cv_nm=../binutils/nm-new$build_exeext
elif test -x nm$build_exeext; then
gcc_cv_nm=./nm$build_exeext
elif test -x $NM_FOR_TARGET; then
gcc_cv_nm="$NM_FOR_TARGET"
else
AC_PATH_PROG(gcc_cv_nm, $NM_FOR_TARGET)
fi])

I'm not sure what the right version of nm/objdump is  - but clearly, one for
the host not the target ...


-- 


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

[Bug c++/44907] SFINAE vs ambiguous base (the real one ;)

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-07-12 15:10 
---
I have a patch (a tiny, straightforward, bit out of my __is_convertible_to
work)


-- 

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 |2010-07-12 15:10:17
   date||


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

[Bug debug/44901] [4.6 Regression] -fcompare-debug failure for tree-predcom.c

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-07-12 15:23 ---
Created an attachment (id=21185)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21185&action=view)
gcc46-pr44901.patch

Untested fix.

Expansion depends on the order of vars in cfun->local_decls, see e.g.
expand_used_vars.  The removal of vars from local_decls sometimes depends on
whether compiling with -g or -g0, and the unordered removal changes the
relative ordering between vars that are going to get pseudos/memory assigned,
which means -g/-g0 affect (resp. might affect) code generation, which is
undesirable.


-- 

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

[Bug tree-optimization/44915] [4.6 Regression] ICE: SIGSEGV in walk_aliased_vdefs_1.constprop.42 (tree-ssa-alias.c:1707) with -findirect-inlining

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-07-12 16:07 ---
It is caused by revision 161384:

http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg01302.html


-- 


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

[Bug target/44919] New: ICE on ia64 with -O3 at sel-sched.c:4672

[joachim dot reichel at gmx dot de]

Using built-in specs.
Target: ia64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.4-6'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --disable-libssp --enable-objc-gc
--with-system-libunwind --enable-checking=release --build=ia64-linux-gnu
--host=ia64-linux-gnu --target=ia64-linux-gnu
Thread model: posix
gcc version 4.4.4 (Debian 4.4.4-6)

The above version of g++ fails with -O3 on the attached test case:

bug.i: In member function
'X::internal::Segment_2_Iso_rectangle_2_pair::Intersection_results
X::internal::Segment_2_Iso_rectangle_2_pair::intersection_type() const [with
K = X::Cartesian]':
bug.i:130: internal compiler error: in move_cond_jump, at sel-sched.c:4672

I don't know whether the code is valid. I guess so because g++ does not
complain on other architectures.

I've minimized the test case with delta and a bit of manual tweaking, but I
can't reduce it further.


-- 
   Summary: ICE on ia64 with -O3 at  sel-sched.c:4672
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joachim dot reichel at gmx dot de
 GCC build triplet: ia64-linux-gnu
  GCC host triplet: ia64-linux-gnu
GCC target triplet: ia64-linux-gnu


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

[Bug target/44919] ICE on ia64 with -O3 at sel-sched.c:4672

[joachim dot reichel at gmx dot de]

--- Comment #1 from joachim dot reichel at gmx dot de  2010-07-12 17:15 
---
Created an attachment (id=21186)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21186&action=view)
test case for bug 44919


-- 


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

[Bug rtl-optimization/44752] insn-automata.c: empty translation unit

[amylaar at gcc dot gnu dot org]

--- Comment #7 from amylaar at gcc dot gnu dot org  2010-07-12 17:16 ---
Subject: Bug 44752

Author: amylaar
Date: Mon Jul 12 17:16:38 2010
New Revision: 162083

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162083
Log:
PR rtl-optimization/44752
* genautomata.c (main): Don't emit an empty file even if there
is no automaton.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/genautomata.c


-- 


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

[Bug libstdc++/44902] eh_arm.cc:42:23: error: declaration of '__cxxabiv1::__cxa_type_match_result __cxa_type_match(_Unwind_Control_Block*, const std::type_info*, bool, void**)' with C language linkage

[rearnsha at gcc dot gnu dot org]

--- Comment #2 from rearnsha at gcc dot gnu dot org  2010-07-12 17:45 
---
Looks to be a valid bug to me.  I suspect it's triggered by the
'--enable-maintainer-mode' flag causing -Werror to be used while building
libstdc++.

Paul, is this just a straight prototype problem in the header file?


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pbrook at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-07-12 17:45:45
   date||


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

[Bug c++/44920] New: const rvalue cast results in internal compiler error

[wsf at fultondesigns dot co dot uk]

>Submitter-Id:net
>Originator:William S Fulton
>Organization:
>Confidential:no
>Synopsis:const rvalue cast results in internal compiler error
>Severity:serious
>Priority:medium
>Category:
>Class:ice-on-legal-code
>Release:gcc-4.5 (GCC) 4.5.0
>Environment:
System: Linux caracal 2.6.27-16-generic #1 SMP Tue Dec 1 17:56:54 UTC 2009 i686
GNU/Linux

host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ./configure --program-suffix=-4.5
>Description:
A rvalue cast involving a const gives internal compiler error
>How-To-Repeat:
$ g++-4.5 -E -std=gnu++0x runme.cxx
# 1 "runme.cxx"
# 1 ""
# 1 ""
# 1 "runme.cxx"

class A {
public:
  void set(const int &&a) {
_a = a;
  }

private:
  int _a;
};

template T Copy(const T& t) {
return T(t);
};

void doit() {
  A a;
  A *arg1 = (A *) &a;
  int arg2 = 0 ;


  (arg1)->set((const int&&)Copy(arg2));
}

int main ()
{
doit();
return 0;
}

$ g++-4.5 -std=gnu++0x runme.cxx
runme.cxx: In function ‘void doit()’:
runme.cxx:22:48: internal compiler error: in cp_build_c_cast, at
cp/typeck.c:6308
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

>Fix:
Remove the cast replacing:

  (arg1)->set((const int&&)Copy(arg2));

with:

  (arg1)->set(Copy(arg2));

Note (fix 2): if 'const int' is replaced with 'int' everywhere, everything
works fine.


-- 
   Summary: const rvalue cast results in internal compiler error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wsf at fultondesigns dot co dot uk
 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=44920

[Bug c++/44920] [C++0x] const rvalue cast results in internal compiler error

[redi at gcc dot gnu dot org]

-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.4.3 4.5.0 4.6.0
   Last reconfirmed|-00-00 00:00:00 |2010-07-12 18:21:32
   date||


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

[Bug c++/44920] [C++0x] const rvalue cast results in internal compiler error

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2010-07-12 18:24 ---
Using static_cast also works, the problem is only with C-style
casts


-- 


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

[Bug target/44816] [4.5/4.6 Regression] ice in subst_reloads, at reload.c:6328

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2010-07-12 18:25 ---
It is caused by revision 149210:

http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00087.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org


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

[Bug bootstrap/44921] New: [4.6 Regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 162085 gave:

../../src-trunk/gcc/postreload.c: In function 'reload_cse_regs':
../../src-trunk/gcc/postreload.c:1327:57: error: 'min_regno' may be used
uninitialized in this function [-Werror=uninitialized]
../../src-trunk/gcc/postreload.c:1284:7: note: 'min_regno' was declared here
cc1: all warnings being treated as errors

It may be caused by revision 162085:

http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00439.html


-- 
   Summary: [4.6 Regression] Failed to bootstrap
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug bootstrap/44921] [4.6 Regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-07-12 18:46 ---
This patch:

Index: postreload.c
===
--- postreload.c(revision 162085)
+++ postreload.c(working copy)
@@ -1281,7 +1281,7 @@ move2add_use_add3_insn (rtx reg, rtx sym
   rtx src = SET_SRC (pat);
   int regno = REGNO (reg);
   int min_cost = INT_MAX;
-  int min_regno;
+  int min_regno = -1;
   bool speed = optimize_bb_for_speed_p (BLOCK_FOR_INSN (insn));
   int i;

@@ -1317,7 +1317,7 @@ move2add_use_add3_insn (rtx reg, rtx sym
  }
   }

-  if (min_cost < rtx_cost (src, SET, speed))
+  if (min_regno >= 0 && min_cost < rtx_cost (src, SET, speed))
 {
   rtx tem;

works for me.


-- 


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

[Bug bootstrap/44921] [4.6 Regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug objc/41848] Extra Objective C test failures because of section anchors.

[iains at gcc dot gnu dot org]

--- Comment #6 from iains at gcc dot gnu dot org  2010-07-12 19:15 ---
(In reply to comment #5)
> I do not see the fails shown in:
> http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg00563.html
> with my current tree [162035] - but I'm using simulator combined tree build -
> with glibc from a Debian distribution (I forget which, but can check if it's
> important).
> 
> -(hopefully) Andrew's analysis is correct (but, I guess I'd like to know why 
> it
> fixed them ... )..

the fails are gone at:
http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg01082.html

which is the first result post 162030 - consistent.


-- 


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

[Bug rtl-optimization/44752] insn-automata.c: empty translation unit

[amylaar at gcc dot gnu dot org]

--- Comment #8 from amylaar at gcc dot gnu dot org  2010-07-12 19:51 ---
Fixed in trunk r162083.


-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug testsuite/44922] New: undefined variable in execute/921202-1.c

[zeccav at gmail dot com]

It seems that at line 28 of execute/921202-1.c the variable cyx is used
undefined.
Can you look into it?
Vittorio Zecca


-- 
   Summary: undefined variable in execute/921202-1.c
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zeccav at gmail dot com
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug testsuite/44923] New: Access beyond array limit in execute/921202-1.c

[zeccav at gmail dot com]

It seems that at line 23 of execute/921202-1.c the array element dy[size] is
accessed beyond thelimit of dy. This is because size=2055 and VLEN=2055.
Can you look into this?
Vittorio Zecca


-- 
   Summary: Access beyond array limit in execute/921202-1.c
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zeccav at gmail dot com
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug c++/44907] SFINAE vs ambiguous base (the real one ;)

[paolo at gcc dot gnu dot org]

--- Comment #2 from paolo at gcc dot gnu dot org  2010-07-12 19:59 ---
Subject: Bug 44907

Author: paolo
Date: Mon Jul 12 19:59:31 2010
New Revision: 162113

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162113
Log:
/cp
2010-07-12  Paolo Carlini  

PR c++/44907
* call.c (build_temp): Add tsubst_flags_t complain parameter;
adjust build_special_member_call call, pass complain.
(convert_like_real): Adjust build_temp call, pass complain.

/testsuite
2010-07-12  Paolo Carlini  

PR c++/44907
* g++.dg/template/sfinae19.C: New.
* g++.dg/template/sfinae20.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/template/sfinae19.C
trunk/gcc/testsuite/g++.dg/template/sfinae20.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/44907] SFINAE vs ambiguous base (the real one ;)

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-07-12 20:00 
---
Fixed for 4.6.0.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0


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

[Bug c++/44924] New: Broken htons, invalid conversion warning

[ralgith at gmail dot com]

I believe this needs to be relooked at. It is still an issue, and the bug seems
to come from the gcc/g++ compilers themselves.

To wit (quoting myself from a board where I was discussing this issue):
~~~Start Self Quote~~~
Outline of the problem:
C++ Software written by someone else for server-to-server communication with
MUD softwares, uses htons()
g++ is spitting out the following error:
error: conversion to ‘short unsigned int’ from ‘int’ may alter its value

That line of code:
sa.sin_port= htons( siteinfo->port );

Other relevant code:
struct sockaddr_in sa;
unsigned short int port;/* Port the server listens on */

Using --save-temps compiiler flag and grepping the resulting .ii file for
htons:
extern uint16_t htons (uint16_t __hostshort)

Checking typedef for unit16_t also using grep on the .ii file:
typedef unsigned short int __uint16_t;

All proper header files for htons() & network sockets (,
 and ) included.

So, am I missing something here... or is this a bad warning from the compiler?

g++ flags in use:
[code]W_FLAGS = -Wall -Werror -Wformat-security -Wshadow -Wpointer-arith
-Wcast-align -Wredundant-decls -Wconversion -pedantic

CFLAGS = -g2 -Os $(W_FLAGS)
LFLAGS = -g2 -lz[/code]

make/g++/ln version infos:
$ make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

$ g++ --version
g++ (GCC) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ ln --version
ln (GNU coreutils) 7.5
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Parker and David MacKenzie.
~~~End Self Quote~~~

Now, as the original reporter of this bug mentioned, it ONLY happens with
higher levels of optimization. Take it or leave it, but this is NOT "invalid".

g++ -v compilation command output:
$ g++ -v -g2 -Os -Wall -Werror -Wformat-security -Wshadow -Wpointer-arith
-Wcast-align -Wredundant-decls -Wconversion -pedantic --save-temps  -c -o imc.o
imc.c
Using built-in specs.
Target: i586-manbo-linux-gnu
Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib
--with-slibdir=/lib --with-bugurl=https://qa.mandriva.com/
--mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release
--enable-languages=c,c++,ada,fortran,objc,obj-c++,java
--build=i586-manbo-linux-gnu --host=i586-manbo-linux-gnu --with-cpu=generic
--with-system-zlib --enable-threads=posix --enable-shared --enable-objc-gc
--enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-clocale=gnu --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-gtk-cairo
--disable-libjava-multilib --enable-ssp --disable-libssp --disable-werror
--with-ppl --with-cloog --with-python-dir=/lib/python2.6/site-packages
Thread model: posix
gcc version 4.4.1 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-g2' '-Os' '-Wall' '-Werror' '-Wformat-security'
'-Wshadow' '-Wpointer-arith' '-Wcast-align' '-Wredundant-decls' '-Wconversion'
'-pedantic' '-save-temps' '-c' '-o' 'imc.o' '-shared-libgcc' '-mtune=generic'
 /usr/lib/gcc/i586-manbo-linux-gnu/4.4.1/cc1plus -E -quiet -v -D_GNU_SOURCE
imc.c -mtune=generic -Wall -Werror -Wformat-security -Wshadow -Wpointer-arith
-Wcast-align -Wredundant-decls -Wconversion -pedantic -g2 -fworking-directory
-Os -fpch-preprocess -o imc.ii
ignoring nonexistent directory
"/usr/lib/gcc/i586-manbo-linux-gnu/4.4.1/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/i586-manbo-linux-gnu/4.4.1/../../../../i586-manbo-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i586-manbo-linux-gnu/4.4.1/../../../../include/c++/4.4.1

/usr/lib/gcc/i586-manbo-linux-gnu/4.4.1/../../../../include/c++/4.4.1/i586-manbo-linux-gnu
 /usr/lib/gcc/i586-manbo-linux-gnu/4.4.1/../../../../include/c++/4.4.1/backward
 /usr/local/include
 /usr/lib/gcc/i586-manbo-linux-gnu/4.4.1/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-g2' '-Os' '-Wall' '-Werror' '-Wformat-security'
'-Wshadow' '-Wpointer-arith' '-Wcast-align' '-Wredundant-decls' '-Wconversion'
'-pedantic' '-save-temps' '-c' '-o' 'imc.o' '-shared-libgcc' '-mtune=generic'
 /usr/lib/gcc/i586-manbo-linux-gnu/4.4.1/cc1plus -fpreprocessed imc.ii -quiet
-dumpbase imc.c -mtune=generic -auxbase-strip imc.o -g2 -Os -Wall -Werror
-Wformat-security -Wshadow -Wpointer-arith -Wcast-align -Wredundant-decls
-Wconversion -pedantic -version -o imc.s
GNU C++ (GCC) version 4.4.1 (i586-manbo-linux-gnu)
compiled by GN

[Bug c++/44924] Broken htons, invalid conversion warning

[ralgith at gmail dot com]

--- Comment #1 from ralgith at gmail dot com  2010-07-12 20:04 ---
Created an attachment (id=21187)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21187&action=view)
Preprocessor output (.ii) file.

This is the output from using --save-temps flag to g++ when trying to compile
the src.


-- 


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

[Bug c++/44924] Broken htons, invalid conversion warning

[ralgith at gmail dot com]

--- Comment #2 from ralgith at gmail dot com  2010-07-12 20:07 ---
This was originally reported and ignored here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39623

Since this ONLY happens with optimization, I'm curious why someone would think
it has multiple defines in the arpa headers?


-- 


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

[Bug c++/44924] Broken htons, invalid conversion warning

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-07-12 20:10 ---
>-Wconversion
Will cause this warning.


   sa.sin_port = (__extension__ ({ register unsigned short int __v, __x =
(siteinfo->port); if (__builtin_constant_p (__x)) __v = __x) >> 8) & 0xff)
| (((__x) & 0xff) << 8)); else __asm__ ("rorw $8, %w0" : "=r" (__v) : "0" (__x)
: "cc"); __v; }));


__v = __x) >> 8) & 0xff) | (((__x) & 0xff) << 8));
is the part which is causing the warning.  The issue is the (__x) >> 8 is
implictly casted into int.


-- 


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

[Bug c++/44924] Broken htons, invalid conversion warning

[ralgith at gmail dot com]

--- Comment #4 from ralgith at gmail dot com  2010-07-12 20:17 ---
(In reply to comment #3)
> >-Wconversion
> Will cause this warning.
> 
> 
>sa.sin_port = (__extension__ ({ register unsigned short int __v, __x =
> (siteinfo->port); if (__builtin_constant_p (__x)) __v = __x) >> 8) & 0xff)
> | (((__x) & 0xff) << 8)); else __asm__ ("rorw $8, %w0" : "=r" (__v) : "0" 
> (__x)
> : "cc"); __v; }));
> 
> 
> __v = __x) >> 8) & 0xff) | (((__x) & 0xff) << 8));
> is the part which is causing the warning.  The issue is the (__x) >> 8 is
> implictly casted into int.
> 

Yet, if I remove the optimization flag -Os and keep the -Wconversion it doesn't
generate the warning. So there's still an issue here, even if the issue is that
-Wconversion is MISSING this when the code isn't optimized. Or perhaps I'm
missing something else here.

Regardless, is there a work around? I really enjoy using all my optimization
and -W flags because I like to have the best code possible. Thanks.


-- 


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

[Bug testsuite/44922] undefined variable in execute/921202-1.c

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-07-12 20:18 ---
Yes it might be but the testcase is ok because the behavior does not really
depend on the uninitialized variable.


-- 


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

[Bug testsuite/44923] Access beyond array limit in execute/921202-1.c

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-07-12 20:21 ---
This testcase is so old, I don't know the history of it :).  It is from 1992.


-- 


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

[Bug objc/41848] Extra Objective C test failures because of section anchors.

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2010-07-12 20:28 ---
(In reply to comment #5)
> -(hopefully) Andrew's analysis is correct (but, I guess I'd like to know why 
> it
> fixed them ... )..

IIRC the issue with section anchors and the objective-c front-end was the decl
was being finialized in size after it had been pushed into the variable cgraph.
 So you moved that pushing later which fixed this issue.  And in fact you can
now test powerpc-linux (or AIX; I think darwin now too) removing the check in
the back-end for objc language and section anchors.


-- 


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

[Bug bootstrap/44455] GCC fails to build if MPFR 3.0.0 (Release Candidate) is used

[marc dot glisse at normalesup dot org]

--- Comment #7 from marc dot glisse at normalesup dot org  2010-07-12 20:34 
---
(In reply to comment #5)
> The patch is okay, but it should be tested with bootstrap, `make install' and 
> a
> smoke test after install with:
> 
> - in-tree GMP, in-tree MPFR 2.3
> - in-tree GMP, in-tree MPFR 3.0
> - out-of-tree GMP, in-tree MPFR 2.3
> - out-of-tree GMP, in-tree MPFR 3.0

Is it enough to test with --enable-languages=c? What is a smoke test, gcc -v?
Does it matter if the system has gmp and mpfr installed, even when doing the
in-tree tests (I hope not, because I won't remove them)?


-- 


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

[Bug fortran/44925] New: [OOP] CLASS pointer reported unassociated to C_LOC

[barron dot bichon at swri dot org]

Consider the following code:

module test

  type :: t
  end type t

  type, extends(t) :: tt
  end type tt

contains

  subroutine get_cptr(tt_cptr)
use iso_c_binding
type(c_ptr) :: tt_cptr
class(t), pointer :: tt_fptr
allocate(tt::tt_fptr)
if (associated(tt_fptr)) tt_cptr = c_loc(tt_fptr)
  end subroutine get_cptr

end module test

At compile-time (using gcc trunk r162082) this gives "Error: Parameter
'tt_fptr' to 'c_loc' at (1) must be either a TARGET or an associated pointer"
even though it has to pass the "if (associated(tt_fptr))" test to execute the
"c_loc" function.


-- 
   Summary: [OOP] CLASS pointer reported unassociated to C_LOC
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: barron dot bichon at swri dot org


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

[Bug testsuite/44701] [4.6 regression] PR44492 fix broke gcc.target/powerpc/asm-es-2.c

[pthaugen at gcc dot gnu dot org]

--- Comment #4 from pthaugen at gcc dot gnu dot org  2010-07-12 21:03 
---
Adding '<>' to the "=m" constraint fixes the testcase, but adding a single '>'
(or '<') results in an error for impossible constraints. This is caused by the
following snippet that was added to reload1.c:

  switch (GET_CODE (XEXP (recog_data.operand[opno], 0)))
{
case PRE_INC:
case POST_INC:
case PRE_DEC:
case POST_DEC:
case PRE_MODIFY:
case POST_MODIFY:
  if (strchr (recog_data.constraints[opno], '<') ==
NULL
  || strchr (recog_data.constraints[opno], '>')
 == NULL)
return 0;
  break;

Should the code be using '&&' instead of '||'?


-- 

pthaugen at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot
   ||org, pthaugen at gcc dot gnu
   ||dot org


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

[Bug testsuite/44701] [4.6 regression] PR44492 fix broke gcc.target/powerpc/asm-es-2.c

[pthaugen at gcc dot gnu dot org]

--- Comment #5 from pthaugen at gcc dot gnu dot org  2010-07-12 21:05 
---
Sorry, recog.c is where the prior code snippet came from.


-- 


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

[Bug fortran/44925] [OOP] C_LOC with CLASS pointer

[janus at gcc dot gnu dot org]

-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2010-07-12 21:09:53
   date||
Summary|[OOP] CLASS pointer reported|[OOP] C_LOC with CLASS
   |unassociated to C_LOC   |pointer


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

[Bug c++/41201] #pragma GCC target ("sse2") doesn't alter __SSE2__ in C++ (as it does in C)

[justin dot lebar+bug at gmail dot com]

--- Comment #2 from justin dot lebar+bug at gmail dot com  2010-07-12 22:09 
---
cc'ing Harsha Jagasia, who wrote sse-22.c and funcspec-9.

I might be willing to put together a patch for this, but I'm totally unfamiliar
with the codebase, so I'd almost surely need some help.


-- 

justin dot lebar+bug at gmail dot com changed:

   What|Removed |Added

 CC||harsha dot jagasia at amd
   ||dot com


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

[Bug c++/41201] #pragma GCC target ("sse2") doesn't alter __SSE2__ in C++ (as it does in C)

[justin dot lebar+bug at gmail dot com]

--- Comment #3 from justin dot lebar+bug at gmail dot com  2010-07-12 22:22 
---
Also cc'ing H.J. Lu, who wrote sse-23.c


-- 

justin dot lebar+bug at gmail dot com changed:

   What|Removed |Added

 CC||hjl at gcc dot gnu dot org


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

[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail

[amylaar at gcc dot gnu dot org]

--- Comment #15 from amylaar at gcc dot gnu dot org  2010-07-12 22:25 
---
COMPILER is based on $(CC) / $(CXX), which during testing are overridden
to become the host compiler, i.e. stage 0 for a bootstrap, so to speak.
We want to use @CC@ / @CXX@ to use the same compiler that the latest compiler
binaries (cc1 etc.) were built with.


-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ro at gcc dot gnu dot org
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c++/44908] SFINAE vs pointer to member via virtual base

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-07-12 22:28 
---
I have a patch for this one too, also from the work on __is_convertible_to.


-- 

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 |2010-07-12 22:28:55
   date||


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

[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail

[amylaar at gcc dot gnu dot org]

--- Comment #16 from amylaar at gcc dot gnu dot org  2010-07-12 22:40 
---
Created an attachment (id=21188)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21188&action=view)
proposed patch

This patch should restore the use of the previous stage compiler for plugins.


-- 


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

[Bug c++/41201] #pragma GCC target ("sse2") doesn't alter __SSE2__ in C++ (as it does in C)

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2010-07-12 22:43 ---
I think the whole "pragma GCC target" is incomplete/broken.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC|hjl at gcc dot gnu dot org  |hjl dot tools at gmail dot
   ||com


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

[Bug bootstrap/44921] [4.6 Regression] Failed to bootstrap

[amylaar at gcc dot gnu dot org]

-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-07-12 22:44:40
   date||


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

[Bug bootstrap/44921] [4.6 Regression] Failed to bootstrap

[amylaar at gcc dot gnu dot org]

--- Comment #2 from amylaar at gcc dot gnu dot org  2010-07-12 22:54 ---
(In reply to comment #1)
> This patch:
> 
> Index: postreload.c
> ===
> --- postreload.c(revision 162085)
> +++ postreload.c(working copy)
> @@ -1281,7 +1281,7 @@ move2add_use_add3_insn (rtx reg, rtx sym
>rtx src = SET_SRC (pat);
>int regno = REGNO (reg);
>int min_cost = INT_MAX;
> -  int min_regno;
> +  int min_regno = -1;
>bool speed = optimize_bb_for_speed_p (BLOCK_FOR_INSN (insn));
>int i;
> 
> @@ -1317,7 +1317,7 @@ move2add_use_add3_insn (rtx reg, rtx sym
>   }
>}
> 
> -  if (min_cost < rtx_cost (src, SET, speed))
> +  if (min_regno >= 0 && min_cost < rtx_cost (src, SET, speed))
>  {
>rtx tem;
> 
> works for me.

The variable can not actually be used uninitalized, since min_cost is
initalized to INT_MAX, and the return type of rtx_cost is int.
So it is enough to shut up the compiler warning, no need to add an
extra test there.  I.e. the first hunk should be sufficient.


-- 


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

[Bug bootstrap/44921] [4.6 Regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2010-07-12 23:33 ---
(In reply to comment #2)
> The variable can not actually be used uninitalized, since min_cost is
> initalized to INT_MAX, and the return type of rtx_cost is int.
> So it is enough to shut up the compiler warning, no need to add an
> extra test there.  I.e. the first hunk should be sufficient.
> 

Does the first chunk count as obvious?


-- 


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

[Bug bootstrap/44921] [4.6 Regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2010-07-12 23:34 ---
(In reply to comment #3)
> (In reply to comment #2)
> > The variable can not actually be used uninitalized, since min_cost is
> > initalized to INT_MAX, and the return type of rtx_cost is int.
> > So it is enough to shut up the compiler warning, no need to add an
> > extra test there.  I.e. the first hunk should be sufficient.
> > 
> 
> Does the first chunk count as obvious?

Maybe

int min_regno = 0;

is faster.



-- 


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

[Bug bootstrap/44921] [4.6 Regression] Failed to bootstrap

[amylaar at gcc dot gnu dot org]

--- Comment #5 from amylaar at gcc dot gnu dot org  2010-07-12 23:45 ---
(In reply to comment #3)
> Does the first chunk count as obvious?

I'd say yes.

My boostraps using that hunk with and without --enable-build-with-cxx on
i686-pc-linux-gnu
have progressed past the stage2/stage3 comparison.

(In reply to comment #4)

> int min_regno = 0;
> 
> is faster.

Yes, it's a cheaper constant on a number of processors in term of
size and speed.

If we really care about compiler run-time efficiency here (and efficiency
for programs that use the same warning regime), we should introduce an
attribute to tell the compiler to treat a variable as initialized even if
it isn't, so that attribute can be used in these cases of the variable
always being assigned before used even if no proof exists inside the rule
system of the compiler.


-- 


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

[Bug bootstrap/44921] [4.6 Regression] Failed to bootstrap

[hjl at gcc dot gnu dot org]

--- Comment #6 from hjl at gcc dot gnu dot org  2010-07-13 00:52 ---
Subject: Bug 44921

Author: hjl
Date: Tue Jul 13 00:51:43 2010
New Revision: 162120

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162120
Log:
Silence gcc warning on min_regno.

2010-07-12  H.J. Lu  

PR bootstrap/44921
* postreload.c (move2add_use_add3_insn): Silence gcc warning
on min_regno.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/postreload.c


-- 


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