[Bug fortran/41137] inefficient zeroing of an array

[jv244 at cam dot ac dot uk]

--- Comment #1 from jv244 at cam dot ac dot uk  2009-08-21 07:02 ---
Just for reference, the difference in time between the two variants is truly
impressive. About a factor of 11 with gcc 4.4 and 8 with gcc 4.5. Given that a
code like CP2K spents sometimes about 5-10% of its time in zeroing stuff, this
would help significantly.

trunk:

> gfortran -O3 -march=native test.f90
> ./a.out
  0.1600
  0.84405303

4.4 branch:
> gfortran -O3 -march=native test.f90
> ./a.out
  0.10400600
  1.1320710

test code:
SUBROUTINE S(a,n)
INTEGER :: n
REAL :: a(n,n,n,n)
a(:,:,:,:)=0.0
END SUBROUTINE

SUBROUTINE S2(a)
REAL :: a(10,10,10,10)
a(:,:,:,:)=0.0
END SUBROUTINE


REAL :: a(10,10,10,10),t1,t2
INTEGER :: I,N
N=10

CALL CPU_TIME(t1)
DO I=1,N
CALL S2(a)
ENDDO
CALL CPU_TIME(t2)
write(6,*) t2-t1

CALL CPU_TIME(t1)
DO I=1,N
CALL S(a,10)
ENDDO
CALL CPU_TIME(t2)
write(6,*) t2-t1

END


-- 


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

[Bug c++/41131] [4.3/4.4/4.5 Regression] non-lvalue in unary `&' wrongly accepted

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2009-08-21 07:08 ---
Subject: Bug 41131

Author: jakub
Date: Fri Aug 21 07:08:15 2009
New Revision: 150985

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150985
Log:
PR c++/41131
* tree.c (lvalue_p_1) : Return clk_none if
not TREE_STATIC.

* g++.dg/expr/unary3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/expr/unary3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/41131] [4.3/4.4/4.5 Regression] non-lvalue in unary `&' wrongly accepted

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2009-08-21 07:10 ---
Subject: Bug 41131

Author: jakub
Date: Fri Aug 21 07:10:36 2009
New Revision: 150986

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150986
Log:
PR c++/41131
* tree.c (lvalue_p_1) : Return clk_none if
not TREE_STATIC.

* g++.dg/expr/unary3.C: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/expr/unary3.C
Modified:
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/tree.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug bootstrap/41136] ld picks up multiple definitions of *fstat*

[ktietz at gcc dot gnu dot org]

--- Comment #1 from ktietz at gcc dot gnu dot org  2009-08-21 07:18 ---
Hello, this issue is new to us. But please report this kind of link failures to
mingw-w64 project itself. This bug is unrelated to gcc itself.
It would be interesting, if you report to mingw-w64 project, which version
(date) of runtime you are using, which binutils version you are using.

Best regards,
Kai


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/41131] [4.3 Regression] non-lvalue in unary `&' wrongly accepted

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2009-08-21 07:23 ---
Fixed for 4.4/4.5 so far.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|UNCONFIRMED
  Known to fail|4.3.0 4.4.0 4.5.0   |4.3.0 4.4.0
  Known to work|3.4.6   |3.4.6 4.4.2 4.5.0
Summary|[4.3/4.4/4.5 Regression]|[4.3 Regression] non-lvalue
   |non-lvalue in unary `&' |in unary `&' wrongly
   |wrongly accepted|accepted


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

[Bug fortran/41137] inefficient zeroing of an array

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2009-08-21 07:39 ---
I think PR31009 is similar.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org


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

[Bug fortran/41137] inefficient zeroing of an array

[jv244 at cam dot ac dot uk]

--- Comment #3 from jv244 at cam dot ac dot uk  2009-08-21 08:29 ---
(In reply to comment #2)
> I think PR31009 is similar.

In fact, this is almost a dup of PR31016, since also here, I'm explicitly
talking about the case of known-to-be-contiguous arrays.


-- 


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

[Bug fortran/41106] [F03] Procedure Pointers with CHARACTER results

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2009-08-21 09:43 ---
Subject: Bug 41106

Author: janus
Date: Fri Aug 21 09:43:04 2009
New Revision: 150987

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150987
Log:
2009-08-21  Janus Weil  

PR fortran/41106
* primary.c (gfc_variable_attr): Make it work also on EXPR_FUNCTION.
(gfc_expr_attr): Use gfc_variable_attr for procedure pointer
components.
* resolve.c (resolve_fl_derived): Handle CHARACTER-valued procedure
pointer components.
* trans-expr.c (gfc_conv_component_ref): Ditto.
(gfc_conv_variable): Ditto.
(gfc_conv_procedure_call): Ditto.
(gfc_trans_pointer_assignment): Ditto.
* trans-types.c (gfc_get_derived_type): Ditto.


2009-08-21  Janus Weil  

PR fortran/41106
* gfortran.dg/proc_ptr_23.f90: New.
* gfortran.dg/proc_ptr_comp_15.f90: New.
* gfortran.dg/proc_ptr_comp_16.f90: New.
* gfortran.dg/proc_ptr_comp_17.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_23.f90
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_15.f90
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_16.f90
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_17.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/41135] Uninitialized variable usage warning broken

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2009-08-21 09:56 ---
I get the warning with FSF 4.4.1 and the 4.5.0 20090813 snapshot, looks like a
problem with ubuntu's 4.4.1


-- 


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

[Bug bootstrap/41136] ld picks up multiple definitions of *fstat*

[t66667 at gmail dot com]

--- Comment #2 from t7 at gmail dot com  2009-08-21 10:36 ---
Hello,
I can confirm this issue have been solved by mingw-w64 (updating mingw-w64-crt)
in the latest source in svn repository
(http://sourceforge.net/projects/mingw-w64/develop).

---
sezero committed revision 1181 to the MinGW-w64 - for 32 and 64 bit Windows SVN
repository, changing 14 files.
---
Thanks again for the fast fix.


-- 


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

[Bug fortran/41053] internal compiler error: in emit_swap_insn, at reg-stack.c:827

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2009-08-21 12:12 ---
> You nee to provide

Please read "You need to provide" (why do we see typos after having hit the
commit button?).

The util_p.f file contains two subroutines and three functions. You may want to
find the culprit(s) by splitting the file in five pieces containing only one
procedure.


-- 


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

[Bug fortran/41106] [F03] Procedure Pointers with CHARACTER results

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2009-08-21 12:17 ---
Fixed with r150987. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/41138] New: Inconsistent (incorrect?) "overflow in implicit constant conversion" warning

[anpaza at mail dot ru]

Given the following testcase:

-
unsigned char foo;

void test ()
{
foo &= 65280;
foo &= 65280L;
foo &= 65280U;

foo &= 0xff00;
foo &= 0xff00L;
foo &= 0xff00U;
}
-

when compiling (gcc -c test.c) there will be warnings emited at first, second,
fourth and fifth expressions but ont at the third and sixth:

test3.c: In function 'test':
test3.c:5: warning: overflow in implicit constant conversion
test3.c:6: warning: overflow in implicit constant conversion
test3.c:9: warning: overflow in implicit constant conversion
test3.c:10: warning: overflow in implicit constant conversion

In my opinion, it should either warn everywhere (overflow because rvalue has
bits set outside of the range of a 'char'), or emit a different warning with
something aboud rvalue signedness.

Also, if you increment all constants by one (e.g. 65281 and 0xff01) all
warnings will disappear. So the warning emited before is either incorrect and
should be never emited in such cases, or should be emited always, but not just
sometimes.


-- 
   Summary: Inconsistent (incorrect?) "overflow in implicit constant
conversion" warning
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anpaza at mail dot ru


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

[Bug fortran/41139] New: [4.5 Regression] a procedure pointer call as actual argument

[janus at gcc dot gnu dot org]

PROGRAM test

 PROCEDURE(add), POINTER :: f

 ! Passing the function works
 print *,greater(4.,add(1.,2.))

 ! Passing the procedure pointer fails
 f => add
 print *,greater(4.,f(1.,2.))

CONTAINS

 REAL FUNCTION add(x,y)
   REAL, INTENT(in) :: x,y
   print *,"add:",x,y
   add = x+y
 END FUNCTION add

 LOGICAL FUNCTION greater(x,y)
   REAL, INTENT(in) :: x, y
   greater = (x > y)
 END FUNCTION greater

END PROGRAM test


This code produces the following output:

 add:   1.000   2.000
 T
 add:   1.000   2.000
Segmentation fault


Looking at the ouput of -fdump-tree-original, one can see a difference between
the two calls to 'greater':

  D.1563 = add (&C.1561, &C.1562);
  D.1564 = greater (&C.1560, &D.1563);

  D.1570 = greater (&C.1567, f (&C.1568, &C.1569));

I.e. in the first case a temporary variable is inserted for the result of
'add', while in the second case this is not the case (which is the reason for
the segfault).

gfortran 4.4 behaves correctly.

Reported by Barron Bichon.


-- 
   Summary: [4.5 Regression] a procedure pointer call as actual
argument
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  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=41139

[Bug fortran/41139] [4.5 Regression] a procedure pointer call as actual argument

[janus at gcc dot gnu dot org]

-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||barron dot bichon at swri
   ||dot org
  Known to fail||4.5.0
  Known to work||4.4.0
   Target Milestone|--- |4.5.0


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

[Bug c/41138] Inconsistent (incorrect?) "overflow in implicit constant conversion" warning

[bugs at nospam dot pz dot podzone dot net]

--- Comment #1 from bugs at nospam dot pz dot podzone dot net  2009-08-21 
13:31 ---
$ cat foo.c
unsigned char foo;

Also note the inconsistency between x86 gcc and avr-gcc:

void test(void)
{
  foo &= ~0xff; /* warning */
  foo &= ~0xfe; /* no warning */

  foo &= 65280; /* warning */
  foo &= 65280L;/* warning */
  foo &= 65280U;/* no warning */
  foo &= 65280LU;   /* no warning */

  foo &= 0xff00;/* warning only with x86 gcc */
  foo &= 0xff00L;   /* warning */
  foo &= 0xff00U;   /* no warning */
  foo &= 0xff00LU;  /* no warning */

  foo &= 65281; /* no warning */
  foo &= 65281L;/* no warning */
  foo &= 65281U;/* no warning */
  foo &= 65281LU;   /* no warning */

  foo &= 0xff01;/* no warning */
  foo &= 0xff01L;   /* no warning */
  foo &= 0xff01U;   /* no warning */
  foo &= 0xff01LU;  /* no warning */
}
$ avr-gcc -c foo.c
foo.c: In function 'test':
foo.c:5: warning: overflow in implicit constant conversion
foo.c:8: warning: overflow in implicit constant conversion
foo.c:9: warning: overflow in implicit constant conversion
foo.c:14: warning: overflow in implicit constant conversion
$ gcc-4 -c foo.c
foo.c: In function 'test':
foo.c:5: warning: overflow in implicit constant conversion
foo.c:8: warning: overflow in implicit constant conversion
foo.c:9: warning: overflow in implicit constant conversion
foo.c:13: warning: overflow in implicit constant conversion
foo.c:14: warning: overflow in implicit constant conversion
$ avr-gcc --version
avr-gcc.exe (WinAVR 20090313) 4.3.2
Copyright (C) 2008 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.

$ gcc-4 --version
gcc-4 (GCC) 4.3.2 20080827 (beta) 2
Copyright (C) 2008 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.

$


-- 

bugs at nospam dot pz dot podzone dot net changed:

   What|Removed |Added

 CC||bugs at nospam dot pz dot
   ||podzone dot net


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

[Bug fortran/41139] [4.5 Regression] a procedure pointer call as actual argument

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2009-08-21 13:35 ---
Beware the forbidden recursive I/Os!-(the test hangs on Darwin, see pr30617).
Otherwise, after using a temp for greater, I get a Bus error.


-- 


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

[Bug fortran/41139] [4.5 Regression] a procedure pointer call as actual argument

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2009-08-21 13:51 ---

> Beware the forbidden recursive I/Os!

This is not the issue here. The following variation has no recursive I/O, but
gives the same segfault:

PROGRAM test

 PROCEDURE(add), POINTER :: f
 logical :: g

 ! Passing the function works
 g=greater(4.,add(1.,2.))
 print *,g

 ! Passing the procedure pointer fails
 f => add
 g=greater(4.,f(1.,2.))
 print *,g

CONTAINS

 REAL FUNCTION add(x,y)
   REAL, INTENT(in) :: x,y
   print *,"add:",x,y
   add = x+y
 END FUNCTION add

 LOGICAL FUNCTION greater(x,y)
   REAL, INTENT(in) :: x, y
   greater = (x > y)
 END FUNCTION greater

END PROGRAM test


-- 


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

[Bug fortran/41139] [4.5 Regression] a procedure pointer call as actual argument

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2009-08-21 13:58 ---
> > Beware the forbidden recursive I/Os!
>
> This is not the issue here. ...

Indeed I know! but 

(1) I had to make the change you have posted in comment #2 to run a test.

(2) The code in comment #0 is illegal and should not be used for the test
suite.


-- 


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

[Bug fortran/41139] [4.5 Regression] a procedure pointer call as actual argument

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2009-08-21 14:00 ---
Side note: If one constructs an analogous test case with PPCs, this does not
have the missing-temporary problem. But it has a different one:

PROGRAM test

 type :: t
   PROCEDURE(add), POINTER, nopass :: f
 end type
 type(t) :: o
 logical :: g

 ! Passing the function works
 g=greater(4.,add(1.,2.))
 print *,g

 ! Passing the procedure pointer fails
 o%f => add
 g=greater(4.,o%f(1.,2.))
 print *,g

CONTAINS

 REAL FUNCTION add(x,y)
   REAL, INTENT(in) :: x,y
   add = x+y
 END FUNCTION add

 LOGICAL FUNCTION greater(x,y)
   REAL, INTENT(in) :: x, y
   print *,"greater:",x,y
   greater = (x > y)
 END FUNCTION greater

END PROGRAM test


The output is:

 greater:   4.000   3.000
 T
 greater:   4.000 -1.49897304E-22
 T

The dump shows the reason for this (a double '&'):

D.1571 = o.f;
D.1572 = D.1571 (&C.1569, &C.1570);
g = (logical(kind=4)) greater (&C.1568, &&D.1572);


-- 


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

[Bug fortran/41139] [4.5 Regression] a procedure pointer call as actual argument

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2009-08-21 14:03 ---

> (1) I had to make the change you have posted in comment #2 to run a test.
> 
> (2) The code in comment #0 is illegal and should not be used for the test
> suite.

Of course. Thanks for pointing this out :)


-- 


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

[Bug inline-asm/41133] Inline Assembler: Constraint A expected different behavior

[andreas dot freimuth at united-bits dot de]

--- Comment #2 from andreas dot freimuth at united-bits dot de  2009-08-21 
14:16 ---
I supposed that the "A" constraints was introduced to support instructions that
use a combination of d and a registers as parameters. These instructions that
use DX:AX, EDX:EAX and RDX:RAX as source or destination still exists in long
mode. But this support is at least for 64bit code completely lost/broken while
there is no int128_t.

As you said: "The "A" constraint supposed to be used for a _PAIR_."
But as I tried to show, GCC does not use any pair in most cases.
  asm("…" :: "A" (0) ); 
This should initialize the _pair_ to 0, shouldn't it?
But gcc initializes only the lower bits (rAX), not the upper (rDX).
And I assume that rDX is not even in the clobber list(but I was not yet able to
prove that), where it definitely has to be.


So if it is supposed to be used for fixed size values, what means no support
for (e)DX:(e)AX in 32bit(64bit) code, I would expect it to work as
  int64_t EDX_EAX = some_32bit_value;
( int128_t RDX_RAX = some_64bit_or_32bit_value; )
with an implicit typecast to be usable for at least some instruction that use
rDX:rAX as operand.


If this is still considered to be no bug in gcc, then the documentation need to
be fixed.


-- 


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

[Bug fortran/41139] [4.5 Regression] a procedure pointer call as actual argument

[janus at gcc dot gnu dot org]

--- Comment #6 from janus at gcc dot gnu dot org  2009-08-21 14:50 ---
This simple patch fixes comment #2:

Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 150987)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -2679,6 +2679,7 @@ gfc_conv_procedure_call (gfc_se * se, gf
}
  else if (e->expr_type == EXPR_FUNCTION
   && e->symtree->n.sym->result
+  && e->symtree->n.sym->result != e->symtree->n.sym
   && e->symtree->n.sym->result->attr.proc_pointer)
{
  /* Functions returning procedure pointers.  */


-- 


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

[Bug fortran/41139] [4.5 Regression] a procedure pointer call as actual argument

[janus at gcc dot gnu dot org]

--- Comment #7 from janus at gcc dot gnu dot org  2009-08-21 15:11 ---
(In reply to comment #4)
> D.1571 = o.f;
> D.1572 = D.1571 (&C.1569, &C.1570);
> g = (logical(kind=4)) greater (&C.1568, &&D.1572);

Btw, it seems unnecessary to me that every PPC call generates a temporary
(D.1571 is this case). This is fixed by the following patchlet:

Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 150987)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -3512,8 +3513,7 @@ gfc_get_proc_ptr_comp (gfc_se *se, gfc_e
   e2 = gfc_copy_expr (e);
   e2->expr_type = EXPR_VARIABLE;
   gfc_conv_expr (&comp_se, e2);
-  comp_se.expr = build_fold_addr_expr_loc (input_location, comp_se.expr);
-  return gfc_evaluate_now (comp_se.expr, &se->pre);  
+  return build_fold_addr_expr_loc (input_location, comp_se.expr);
 }




-- 


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

[Bug target/41140] New: [4.5 Regression] arm.c:3775:11: error: enum conversion in initialization is invalid in C++

[danglin at gcc dot gnu dot org]

/home/dave/gnu/gcc/objdir/./prev-gcc/xgcc
-B/home/dave/gnu/gcc/objdir/./prev-gcc
/ -B/home/dave/opt/gnu/gcc/gcc-4.5.0/armv5tejl-unknown-linux-gnueabi/bin/
-B/hom
e/dave/opt/gnu/gcc/gcc-4.5.0/armv5tejl-unknown-linux-gnueabi/bin/
-B/home/dave/o
pt/gnu/gcc/gcc-4.5.0/armv5tejl-unknown-linux-gnueabi/lib/ -isystem
/home/dave/op
t/gnu/gcc/gcc-4.5.0/armv5tejl-unknown-linux-gnueabi/include -isystem
/home/dave/
opt/gnu/gcc/gcc-4.5.0/armv5tejl-unknown-linux-gnueabi/sys-include-c  -g -O2
-DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-pr
ototypes -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macro
s -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I/home/dave/opt/gnu/include  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber  
-I/home/dave/opt/gnu/include \
../../gcc/gcc/config/arm/arm.c -o arm.o
cc1: warnings being treated as errors
../../gcc/gcc/config/arm/arm.c: In function 'aapcs_vfp_allocate':
../../gcc/gcc/config/arm/arm.c:3775:11: error: enum conversion in
initialization is invalid in C++
../../gcc/gcc/config/arm/arm.c: In function 'aapcs_vfp_allocate_return_reg':
../../gcc/gcc/config/arm/arm.c:3842:4: error: enum conversion when passing
argument 1 of 'gen_rtx_REG' is invalid in C++
../../gcc/gcc/rtl.h:1971:12: note: expected 'enum machine_mode' but argument is
of type 'int'
make[3]: *** [arm.o] Error 1

-bash-3.2$ ./xgcc -B./ -v
Reading specs from ./specs
Target: armv5tejl-unknown-linux-gnueabi
Configured with: ../gcc/configure --host=armv5tejl-unknown-linux-gnueabi
--target=armv5tejl-unknown-linux-gnueabi
--build=armv5tejl-unknown-linux-gnueabi --enable-languages=c,c++,fortran
--enable-shared --enable-threads --disable-multilib --disable-libmudflap
--disable-libssp --enable-symvers=gnu --enable-__cxa_atexit
--disable-libstdcxx-pch --prefix=/home/dave/opt/gnu/gcc/gcc-4.5.0
--with-gmp=/home/dave/opt/gnu
Thread model: posix
gcc version 4.5.0 20090820 (experimental) [trunk revision 150976] (GCC)


-- 
   Summary: [4.5 Regression]  arm.c:3775:11: error: enum conversion
in initialization is invalid in C++
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org


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

[Bug target/41140] [4.5 Regression] arm.c:3775:11: error: enum conversion in initialization is invalid in C++

[rearnsha at gcc dot gnu dot org]

--- Comment #1 from rearnsha at gcc dot gnu dot org  2009-08-21 16:17 
---
Fixed.  Although I posted the patch for this to the mailing list several days
ago (Aug 12 IIRC), I somehow failed to actually commit the code.  Now done.

Sorry about that.


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/41141] New: Support for C++0x standard layout and trivial types is broken

[eric dot niebler at gmail dot com]

GCC is claiming support for Standard Layout Types
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm) in its 4.4
series. However, the following example, taken directly from n2342, fails to
compile (with either --std=gnu++0x or --std=c++0x):

{{{
 #include 

 struct B
 {
   int n;
   B() = default;
   B(int n_) : n(n_) {}
 };

 static_assert(std::is_pod::value, "B is not POD!");

 int main() {}
}}}

I have checked with Beman Dawes, the author of n2342, and he confirms that the
code should compile under a conforming c++0x compiler.


-- 
   Summary: Support for C++0x standard layout and trivial types is
broken
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com


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

[Bug c++/41141] Support for C++0x standard layout and trivial types is broken

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2009-08-21 16:30 ---
I think the docs for 4.4 might be lying, or maybe it's just std::is_pod that
doesn't work correctly.

It works with 4.5, probably since bug 37907 was fixed.


-- 


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

[Bug web/41141] Support for C++0x standard layout and trivial types is broken

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-08-21 16:35 
---
Right, this is just a bug in the 4.4 cxx0x_status.html, I'll fix it
momentarily.


-- 

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
  Component|c++ |web
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-21 16:35:23
   date||


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

[Bug web/41141] Support for C++0x standard layout and trivial types is broken

[redi at gcc dot gnu dot org]

--- Comment #3 from redi at gcc dot gnu dot org  2009-08-21 16:39 ---
Does the C++0x status in the libstdc++ manual also need updating?  it says
is_system_layout is missing - I think that should be is_standard_layout, but
it's not missing on trunk now anyway.


-- 


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

[Bug web/41141] Support for C++0x standard layout and trivial types is broken

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-08-21 16:42 
---
Fixed. Jonathan, probably, let's deal with the separately.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/41142] New: make implicit pointer conversions an error when sizeof(int) != sizeof(void *)

[dannf at dannf dot org]

Implicit pointer conversions on ia64 are guaranteed to result in a segfault if
the value is dereferenced. This issue can be easily identified by looking for a
combination of gcc warnings. In fact, I have been running all of the build logs
or the Debian distribution through a script that scans for this issue for
several years, and it has caught hundreds of these problems:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=da...@debian.org;which=tag&data=implicit-pointer-conversion&archive=no

script here: http://people.debian.org/~dannf/check-implicit-pointer-functions

I don't know anything about gcc internals, but I'm wondering if it is possible
to generate an error when the appropriate combination of warning conditions is
present?


-- 
   Summary: make implicit pointer conversions an error when
sizeof(int) != sizeof(void *)
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannf at dannf dot org


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

[Bug c++/19291] Warning "cannot pass objects of non-POD type" should be an error

[redi at gcc dot gnu dot org]

--- Comment #7 from redi at gcc dot gnu dot org  2009-08-21 16:51 ---
The relevant text in the standard is changing to make it
conditionally-supported, and it's now documented that this isn't supported by
GCC:
http://gcc.gnu.org/onlinedocs/gcc/Conditionally_002dsupported-behavior.html

On that basis it seems correct to make it a hard error for -std=c++0x at least.


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


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

[Bug c/41142] make implicit pointer conversions an error when sizeof(int) != sizeof(void *)

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2009-08-21 17:03 ---
-Werror=int-to-pointer-cast will make one class of warnings into errors, but I
don't think there's a switch to handle the other cases your script detects.


-- 


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

[Bug web/41141] Support for C++0x standard layout and trivial types is broken

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2009-08-21 17:05 
---
Jon, I had a look and apparently the xml file in the v3 doc directory needs
*many* more fixes/updates besides that one. If you can find the time, a more
comprehensive patch would be really welcome, otherwise, I'll try to do it, at
some point.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||redi at gcc dot gnu dot org


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

[Bug fortran/41139] [4.5 Regression] a procedure pointer call as actual argument

[dominiq at lps dot ens dot fr]

--- Comment #8 from dominiq at lps dot ens dot fr  2009-08-21 17:08 ---
With the patch in comment #7, compiling gcc/fortran/trans-expr.c fails with:

...
cc1: warnings being treated as errors
../../gcc-4.5-work/gcc/fortran/trans-expr.c: In function
'gfc_get_proc_ptr_comp':
../../gcc-4.5-work/gcc/fortran/trans-expr.c:3508:32: error: unused parameter
'se'
...


-- 


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

[Bug libobjc/34315] libobjc warnings with Win64 target=x86_64-pc-mingw32

[ktietz at gcc dot gnu dot org]

-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ktietz at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-21 17:25:39
   date||


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

[Bug libstdc++/37907] [c++0x] support for std::is_standard_layout

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug fortran/41139] [4.5 Regression] a procedure pointer call as actual argument

[burnus at gcc dot gnu dot org]

--- Comment #9 from burnus at gcc dot gnu dot org  2009-08-21 18:02 ---
Working: 2009-07-10, r149458
Failing: 2009-07-17, r149734


-- 


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

[Bug fortran/41139] [4.5 Regression] a procedure pointer call as actual argument

[burnus at gcc dot gnu dot org]

--- Comment #10 from burnus at gcc dot gnu dot org  2009-08-21 18:03 ---
(In reply to comment #9)
> Working: 2009-07-10, r149458
> Failing: 2009-07-17, r149734
Wrong PR - sorry, that should go to PR debug/40660


-- 


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

[Bug debug/40660] [4.5 Regression] Wierd break points with 4.5, works with 4.4

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2009-08-21 18:04 ---
Working: 2009-07-10, r149458
Failing: 2009-07-17, r149734


-- 


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

[Bug fortran/41143] New: Support DW_TAG_common_inclusion

[burnus at gcc dot gnu dot org]

See also PR 37738, especially PR 37738 comment 5 and 7.

The DWARF3 standard (http://dwarfstd.org/Dwarf3.pdf) has the following. While
nice in principle, there are some potential problems (see PR 37738).

"3.3.4 Declarations Owned by Subroutines and Entry Points"
"The entry for a subroutine that includes a Fortran common block has a child
entry with the tag DW_TAG_common_inclusion. The common inclusion entry has a
DW_AT_common_reference attribute whose value is a reference to the debugging
entry for the common block being included (see Section 4.2)."


-- 
   Summary: Support DW_TAG_common_inclusion
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 24546
 nThis:


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

[Bug debug/37738] Fortran DW_TAG_common_block has incorrect placement/scope

[burnus at gcc dot gnu dot org]

--- Comment #8 from burnus at gcc dot gnu dot org  2009-08-21 18:16 ---
(In reply to comment #7)
> I have a request to emit a DW_TAG_common_inclusion record in our dwarf output
> for Fortran named commons.  [...]
> I'm just curious about views on this and if gfortran has any plans to 
> implement
> support for DW_TAG_common_inclusion.

Currently, there no plan to implement it; simply because there was no request
for it and other items seem to be more important. I create PR 41143 to track
this, but I do not think that anyone will do much about it any time soon - that
includes thinking about how and whether to implement it. (But I might be wrong
and it might get implemented/considered sooner than I think.)


-- 


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

[Bug c++/41131] [4.3 Regression] non-lvalue in unary `&' wrongly accepted

[sergei_lus at yahoo dot com]

--- Comment #9 from sergei_lus at yahoo dot com  2009-08-21 18:17 ---

This patch works for me. Thanks. 


-- 


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

[Bug libmudflap/40778] [4.5 Regression] Mudflap instrumentation missing in cloned function.

[danglin at gcc dot gnu dot org]

--- Comment #3 from danglin at gcc dot gnu dot org  2009-08-21 18:33 ---
Also seen on hppa-unknown-linux-gnu.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-21 18:33:17
   date||


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

[Bug debug/40660] [4.5 Regression] Wierd break points with 4.5, works with 4.4

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2009-08-21 18:34 ---
Aldy, I think your patch (r149722, PR 40435) might have caused this. Could you
have a look?


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu dot org


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

[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2009-08-21 18:40 ---
What is actually the status of this PR? I read through it twice and I still do
not know whether this is a GCC bug or a GNU ld bug - and, if the former, how it
is supposed to be fixed.


-- 


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

[Bug fortran/29697] gfortran should use TYPE_QUAL_CONST etc.

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2009-08-21 18:44 ---
TYPE_QUAL_RESTRICT is now supported, see
http://gcc.gnu.org/ml/fortran/2009-08/msg00208.html
TYPE_QUAL_CONST is to my knowledge a no op, for QUAL_VOLATILE, I have not
checked whether it is already (correctly) used or not - according to comment 4
they are.


-- 


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

[Bug target/40786] Windows %I32 format confusion

[ktietz at gcc dot gnu dot org]

--- Comment #4 from ktietz at gcc dot gnu dot org  2009-08-21 19:22 ---
As to see on Wiki
http://en.wikipedia.org/wiki/Printf#printf_format_placeholders

%I32 means, for integer types, causes to expect a 32-bit (double word) integer
argument. May tests have shown that long type and int type arguments are valid
here.


-- 


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

[Bug target/39819] [avr] Missed optimisation when setting 4-byte values

[eric dot weddington at atmel dot com]

--- Comment #1 from eric dot weddington at atmel dot com  2009-08-21 19:28 
---
Confirmed on 4.3.2.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.3.2
   Last reconfirmed|-00-00 00:00:00 |2009-08-21 19:28:03
   date||


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

[Bug c++/41144] New: ice for legal code with -O2 in get_alias_set

[dcb314 at hotmail dot com]

I just tried to compile Suse Linux package agg-2.5-158.64
with the g++ 4.5 mainline snapshot 20090820
and the compiler said

In file included from aa_test.cpp:13:0:
../include/agg_span_gouraud_rgba.h: In member function 'void
agg::span_gouraud_rgba::prepare() [with ColorT = agg::rgba8]':
../include/agg_span_gouraud_rgba.h:127:31: internal compiler error: in
get_alias_set, at alias.c:694
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source attached. Flag -O2 required.


-- 
   Summary: ice for legal code with -O2 in get_alias_set
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug c++/41144] ice for legal code with -O2 in get_alias_set

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2009-08-21 20:00 ---
Created an attachment (id=18409)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18409&action=view)
C++ source code


-- 


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

[Bug rtl-optimization/39510] [avr] missed optimisation with IO read and register variables

[eric dot weddington at atmel dot com]

--- Comment #6 from eric dot weddington at atmel dot com  2009-08-21 20:10 
---
Confirmed on 4.3.2.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.3.3 4.3.2
   Last reconfirmed|-00-00 00:00:00 |2009-08-21 20:10:06
   date||


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

[Bug fortran/41139] [4.5 Regression] a procedure pointer call as actual argument

[janus at gcc dot gnu dot org]

--- Comment #11 from janus at gcc dot gnu dot org  2009-08-21 20:27 ---
Here is another variant of the test case which fails at runtime:

PROGRAM test

 type :: t
   PROCEDURE(three), POINTER, nopass :: f
 end type
 type(t) :: o
 logical :: g

 o%f => three
 g=greater(4.,o%f())
 print *,g

CONTAINS

 REAL FUNCTION three()
   three = 3.
 END FUNCTION

 LOGICAL FUNCTION greater(x,y)
   REAL, INTENT(in) :: x, y
   print *,"greater:",x,y
   greater = (x > y)
 END FUNCTION greater

END PROGRAM test


The dump shows:

g = (logical(kind=4)) greater (&C.1561, &o.f);


-- 


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

[Bug debug/40660] [4.5 Regression] Wierd break points with 4.5, works with 4.4

[aldyh at gcc dot gnu dot org]

--- Comment #7 from aldyh at gcc dot gnu dot org  2009-08-21 21:11 ---
Sorry I was out on vacation.  I will take a look.


-- 


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

[Bug c++/41109] [4.5 regression] Argument flagged as unused despite use in sizeof()

[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|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-21 21:46:27
   date||


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

[Bug c++/41110] [4.5 regression] Wrong "unused variable" warning

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2009-08-21 21:46 ---


*** This bug has been marked as a duplicate of 41109 ***


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/41109] [4.5 regression] Argument flagged as unused despite use in sizeof()

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2009-08-21 21:46 ---
*** Bug 41110 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/41134] [4.5 regression] Variable flagged unused if only used in template function

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2009-08-21 21:47 ---


*** This bug has been marked as a duplicate of 41109 ***


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/41109] [4.5 regression] Argument flagged as unused despite use in sizeof()

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2009-08-21 21:47 ---
*** Bug 41134 has been marked as a duplicate of this bug. ***


-- 


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

[Bug testsuite/39776] FAIL: g++.dg/ext/altivec-15.C

[meissner at gcc dot gnu dot org]

-- 

meissner at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |meissner at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-04-21 17:15:06 |2009-08-21 22:15:05
   date||


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

[Bug target/41145] New: My VSX changes broke gcc.dg/dfp/altivec-types.c

[meissner at gcc dot gnu dot org]

My VSX changes broke reporting of some error messages, such as __vector
_Decimal128 unless -mvsx was used.


-- 
   Summary: My VSX changes broke gcc.dg/dfp/altivec-types.c
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: meissner at gcc dot gnu dot org
ReportedBy: meissner at gcc dot gnu dot org
 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=41145

[Bug target/41145] My VSX changes broke gcc.dg/dfp/altivec-types.c

[meissner at gcc dot gnu dot org]

--- Comment #1 from meissner at gcc dot gnu dot org  2009-08-21 22:47 
---
Created an attachment (id=18410)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18410&action=view)
Restore error messages broken by VSX changes


-- 


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

[Bug testsuite/40671] [4.5 Regression] internal compiler error: in extract_insn, at recog.c:2089 on powerpc

[meissner at gcc dot gnu dot org]

--- Comment #5 from meissner at gcc dot gnu dot org  2009-08-21 22:48 
---
Created an attachment (id=18411)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18411&action=view)
Use correct target test to size pointers.


-- 


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

[Bug c/40977] Problem with code like this: res = ((uint64_t)resh << 32) | resl;

[ami_stuff at o2 dot pl]

--- Comment #1 from ami_stuff at o2 dot pl  2009-08-22 00:43 ---
Here is asm output from GCC 4.2.5 (-m68060 -fomit-frame-pointer -O3):

#NO_APP
.text
.even
.globl  _MUL64
_MUL64:
movm.l #0x3e00,-(sp)
move.l 24(sp),a1
move.l 28(sp),a0
#APP
| Inlined umul_ppmm
move.l a1,d0
move.l a0,d1
move.l d0,d2
swapd0
move.l d1,d3
swapd1
move.w d2,d4
mulud3,d4
mulud1,d2
mulud0,d3
mulud0,d1
move.l d4,d0
eor.w  d0,d0
swapd0
add.l  d0,d2
add.l  d3,d2
jcc 1f
add.l  #65536,d1
1:  swapd2
moveq   #0,d0
move.w d2,d0
move.w d4,d2
move.l d2,d6
add.l  d1,d0
move.l d0,d5
#NO_APP
tst.l a1
jblt L8
L2:
tst.l a0
jbge L4
sub.l a1,d5
jbra L4
L8:
sub.l a0,d5
jbra L2
L4:
move.l d5,d0
clr.l d1
or.l d6,d1
movm.l (sp)+,#0x7c
rts


GCC 4.3.2 asm output looks worse:

#NO_APP
.text
.even
.globl  _MUL64
_MUL64:
movem.l #15872,-(sp)
move.l 24(sp),d5
move.l 28(sp),a1
#APP
;# 45 "test2.c" 1
| Inlined umul_ppmm
move.l d5,d0
move.l a1,d1
move.l d0,d2
swapd0
move.l d1,d3
swapd1
move.w d2,d4
mulud3,d4
mulud1,d2
mulud0,d3
mulud0,d1
move.l d4,d0
eor.w  d0,d0
swapd0
add.l  d0,d2
add.l  d3,d2
jcc 1f
add.l  #65536,d1
1:  swapd2
moveq   #0,d0
move.w d2,d0
move.w d4,d2
move.l d2,d6
add.l  d1,d0
move.l d0,a0
#NO_APP
tst.l d5
jlt L6
tst.l a1
jlt L7
L3:
move.l a0,d1
clr.l d2
or.l d6,d2
move.l d1,d0
move.l d2,d1
movem.l (sp)+,#124
rts
L7:
sub.l d5,a0
move.l a0,d1
clr.l d2
or.l d6,d2
move.l d1,d0
move.l d2,d1
movem.l (sp)+,#124
rts
L6:
sub.l a1,a0
tst.l a1
jge L3
jra L7


-- 


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