[Bug fortran/43207] New: [OOP] ICE for invalid pointer assignment => type%parent

[burnus at gcc dot gnu dot org]

gfortran
fff.f90: In function 'foo_child':
fff.f90:26:0: internal compiler error: in gfc_conv_structure, at
fortran/trans-expr.c:4390

NAG:
Error: fff.f90, line 29: THIS is neither a POINTER nor a TARGET
   detected at PARENT@

IBM:
"Final_test.F90", line 27.20: 1514-648 (S) A structure component
reference must be polymorphic if the rightmost component name is of
abstract type.


 module parent_module
  implicit none

  type ,abstract :: parent
  contains
procedure :: foo
  end type

contains
  subroutine foo(this)
class(parent) :: this
print *,'Inside parent foo'
  end subroutine
end module

module child_module
  use parent_module
  implicit none

  type ,extends(parent) :: child
  contains
procedure :: foo => foo_child
  end type

contains
  subroutine foo_child(this)
class(child) :: this
class(parent) ,pointer :: this_parent=>null()
this_parent => this%parent  ! 
print *,'Inside child foo'
call this_parent%foo()
  end subroutine
end module


-- 
   Summary: [OOP] ICE for invalid pointer assignment  => type%parent
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug ada/43096] [4.5 regression] miscompilation of ACATS c37105a at -O2

[laurent at guerby dot net]

--- Comment #10 from laurent at guerby dot net  2010-02-28 09:05 ---

Fixed on arm-linux
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg02695.html

powerpc-linux:
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg02720.html

Thanks!


-- 


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

[Bug other/42980] GCC parallel "make install" failures

[rwild at gcc dot gnu dot org]

--- Comment #11 from rwild at gcc dot gnu dot org  2010-02-28 09:57 ---
Patches posted at 


-- 


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

[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux

[aph at gcc dot gnu dot org]

--- Comment #12 from aph at gcc dot gnu dot org  2010-02-28 10:07 ---
I can't duplicate this problem with gcc trunk and binutils 2.20-0ubuntu2.


-- 


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

[Bug fortran/43207] [OOP] ICE for invalid pointer assignment => type%parent

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-02-28 10:18 ---
Possibly related:
  implicit none
  type, abstract :: parent
integer :: i
  end type

  type, extends(parent) :: child
  end type
  type(child) :: c1, c1a
  class(child), allocatable :: c2
  print *, c1%parent%i
  print *, c2%parent%i
  c1a%parent = c1%parent !<<< LHS & RHS invalid
  c1a%parent = c2%parent !<<< LHS invalid
end

Here, c1a%parent and c1%parent is clearly invalid according to C613; for the
rest - I don't know. See also PR 43193. It boils down to understand what makes
data-ref polymorphic - maybe my renewed interpretation of PR 43193 is wrong and
the patch in PR 43193 is still correct?!?

R612  data-ref  is  part-ref % part-ref
R613  part-ref  is  part-name [ ( section-subscript-list ) ]
C611  (R612) If the rightmost part-name is of abstract type, data-ref shall be
polymorphic.

If one finally understands what exactly is meant by this, one should add a
proper error message to  gfc_match_varspec, which saves one of having the check
all over the place.


-- 


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

[Bug bootstrap/38388] parallel install failures in install-{libiberty,gnatlib}

[pluto at agmk dot net]

--- Comment #5 from pluto at agmk dot net  2010-02-28 10:41 ---


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


-- 

pluto at agmk dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug other/42980] GCC parallel "make install" failures

[pluto at agmk dot net]

--- Comment #12 from pluto at agmk dot net  2010-02-28 10:41 ---
*** Bug 38388 has been marked as a duplicate of this bug. ***


-- 

pluto at agmk dot net changed:

   What|Removed |Added

 CC||pluto at agmk dot net


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2010-02-28 10:59 ---
Although this pr report a problem for parallel make without install it may be a
duplicate of pr38388.
See also http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01236.html .


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 CC||Ralf dot Wildenhues at gmx
   ||dot de


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

[Bug bootstrap/38388] parallel install failures in install-{libiberty,gnatlib}

[rwild at gcc dot gnu dot org]

--- Comment #6 from rwild at gcc dot gnu dot org  2010-02-28 11:08 ---
Actually, except for the libiberty failure, these failures are different, and
not fixed by the patches for PR 42980.  De-duplicating and reopening.

Can you still reproduce the Ada-related failures? It looks like serialization
between toplevel install-libada and some installation below gcc/ada may be
needed.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[rwild at gcc dot gnu dot org]

--- Comment #5 from rwild at gcc dot gnu dot org  2010-02-28 11:15 ---
(In reply to comment #4)
> Although this pr report a problem for parallel make without install it may be 
> a
> duplicate of pr38388.

That seems unlikely to me.  The cited PR does not change nor concern 'make all'
semantics.  It would however be interesting to know whether this PR is
reproducible with parallel make only.

Building libgomp in earlier stages was done for PR 36101 and PR 42813.


-- 


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

[Bug ada/42253] [4.4/4.5 regression] run time crash on null for thin pointers

[baldrick at gcc dot gnu dot org]

--- Comment #9 from baldrick at gcc dot gnu dot org  2010-02-28 11:18 
---
Yes, that did the trick.  Thanks for fixing this!


-- 


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

[Bug fortran/43178] Pointless resetting to NULL for local ALLOCATABLEs

[dominiq at lps dot ens dot fr]

--- Comment #13 from dominiq at lps dot ens dot fr  2010-02-28 11:20 ---
> Thanks for testing! In trans-array.c's gfc_trans_deferred_array, my current
> version has
>
> - if (sym->value)
> + if (sym->value == NULL || !has_default_initializer (sym->ts.u.derived))
>   ^^
>   This part is new
>
> Hopefully, that is all what is needed. 

Apparently, yes (all my tests pass now).

Following pr43205, I have found an other issue. I don't see this pr with
patched trunk, but with all my other builds. So I have slightly changed the
test to 

  subroutine testproblem
  integer nsub_sta(1146, 2000), nsub_sto(1146, 2000)

  write (*,*) nsub_sta(1000,1000)
  write (*,*) nsub_sto(1000,1000)

  return
  end
  call testproblem
end

With revision 156618 I get

[macbook] f90/bug% time gfc_c -fno-automatic -finit-integer=-100 pr43205_db.f90
4.575u 0.463s 0:06.59 76.3% 0+0k 1+25io 0pf+0w
[macbook] f90/bug% a.out
-100
-100

but with my patched trunk I get

[macbook] f90/bug% time gfc -fno-automatic -finit-integer=-100 pr43205_db.f90
0.019u 0.022s 0:00.04 75.0% 0+0k 0+0io 0pf+0w
[macbook] f90/bug% a.out
   0
   0
[macbook] f90/bug% time gfc -finit-integer=-100 pr43205_db.f90
0.022u 0.022s 0:00.05 80.0% 0+0k 0+8io 0pf+0w
[macbook] f90/bug% a.out
-100
-100

So the patch breaks -finit-integer when used with -fno-automatic.

> Still, the patch needs to be audited - I wouldn't be surprised 
> if some "free" were missing, leading to memory leakage in the generated code.

>  /* Subroutine of gfc_trans_assignment that actually scalarizes the
> -   assignment.  EXPR1 is the destination/LHS and EXPR2 is the source/RHS.  */
> +   assignment.  EXPR1 is the destination/LHS and EXPR2 is the source/RHS.
> +   init_flag indicates initialization expressions, no_free that no
  ^^^
> +   deallocate prior assignment is needed (if in doubt, set true).  */
> 
>  static tree
> -gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag)
> +gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
> + bool dealloc)
 ^^^

It seems that no_free has been changed to dealloc. My knowledge of gfortran is
too bad to allow me to do any audit beyond this point!-(


-- 


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

[Bug fortran/43205] -finit-local-zero and -fno-automatic used together with large 2-dim variables take too long to compile

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2010-02-28 11:20 ---
Confirmed as a regression (see pr43178 comment #13 for the modified test case):

trunk revision 156618

[macbook] f90/bug% time gfc_c -fno-automatic -finit-integer=-100 pr43205_db.f90
4.575u 0.463s 0:06.59 76.3% 0+0k 1+25io 0pf+0w
[macbook] f90/bug% a.out
-100
-100

gfortran 4.4.2

[macbook] f90/bug% time gfortran -fno-automatic -finit-integer=-100
pr43205_db.f90
0.025u 0.032s 0:00.57 8.7%  0+0k 4+19io 0pf+0w
[macbook] f90/bug% a.out
-100
-100


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

--- Comment #6 from dominiq at lps dot ens dot fr  2010-02-28 11:29 ---
> It would however be interesting to know whether this PR is
> reproducible with parallel make only.

Indeed, but so far it is not (see comment #3). Do you have any idea of what I
could do to make it reproducible?


-- 


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

[Bug lto/43208] New: lto1: error: invalid conversion in return statement

[d dot g dot gorbachev at gmail dot com]

In function 'g':
lto1: error: invalid conversion in return statement
struct list_node *

struct list_node *

return D.2037_1;

lto1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /usr/local/bin/i686-pc-linux-gnu-gcc-4.5.0 returned 1 exit status
collect2: lto-wrapper returned 1 exit status


-- 
   Summary: lto1: error: invalid conversion in return statement
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot g dot gorbachev at gmail dot com
 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=43208

[Bug lto/43208] lto1: error: invalid conversion in return statement

[d dot g dot gorbachev at gmail dot com]

--- Comment #1 from d dot g dot gorbachev at gmail dot com  2010-02-28 
11:40 ---
Created an attachment (id=19985)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19985&action=view)
Testcase


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[rwild at gcc dot gnu dot org]

--- Comment #7 from rwild at gcc dot gnu dot org  2010-02-28 11:42 ---
(In reply to comment #6)
> > It would however be interesting to know whether this PR is
> > reproducible with parallel make only.
> 
> Indeed, but so far it is not (see comment #3).

What does your reply mean?  Does it mean "the comparison error is reproducible
only when I use parallel make"?  Or does it mean "the comparison error is not
reproducible with non-parallel make"?  Or do you make a statement about
non-reproducibility of some sort?  These statements are all different, and
comment #3 does not state anything that I can make sense of, except that the
error has been seen to happen with both -j3 and with -j2.

Please do not answer with yes or no, make it easy for readers to follow you by
formulating a full sentence statement as to what you mean.  Thank you.


-- 


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

[Bug tree-optimization/42585] [4.5 Regression] SRA is not good for structure copies with one replacement any more

[mikpe at it dot uu dot se]

--- Comment #9 from mikpe at it dot uu dot se  2010-02-28 11:53 ---
(In reply to comment #8)
> Subject: Bug 42585
> 
> Author: hjl
> Date: Sun Feb  7 04:41:22 2010
> New Revision: 156562
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156562
> Log:
> Backport testcases from mainline to 4.4.
> 
> 2010-02-06  H.J. Lu  
> 
> Backport from mainline:
...
> PR tree-optimization/42585
> * gcc.dg/tree-ssa/pr42585.c: New test.

This caused testsuite regressions for 4.4 on (at least) powerpc64 and arm:
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg02633.html
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg02441.html

Note that this test case also fails on trunk for (at least) powerpc64 and arm:
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg02728.html
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg02695.html


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

--- Comment #8 from dominiq at lps dot ens dot fr  2010-02-28 11:59 ---
(In reply to comment #7)
> Please do not answer with yes or no, make it easy for readers to follow you by
> formulating a full sentence statement as to what you mean.  Thank you.

On a Core2 Duo (x86_64-apple-darwin10), I see the libgomp comparison fails in a
no reproducible way with both -j2 and -j3 (probability since the first
occurrence at r 156585: 4 times for 9 full bootstraps). I have never seen this
failure appearing twice in a raw, i.e., cleaning the build directory and
restarting the bootstrap has always worked.

On a monoprocessor G5 (powerpc-apple-darwin9) on which I always do a non
parallel build, I have never seen a libgomp comparison failure.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[rwild at gcc dot gnu dot org]

--- Comment #9 from rwild at gcc dot gnu dot org  2010-02-28 12:22 ---
(In reply to comment #8)
> On a Core2 Duo (x86_64-apple-darwin10), I see the libgomp comparison fails in 
> a
> no reproducible way with both -j2 and -j3 (probability since the first
> occurrence at r 156585: 4 times for 9 full bootstraps). I have never seen this
> failure appearing twice in a raw, i.e., cleaning the build directory and
> restarting the bootstrap has always worked.
> 
> On a monoprocessor G5 (powerpc-apple-darwin9) on which I always do a non
> parallel build, I have never seen a libgomp comparison failure.

Thank you, very well.  Can you (or somebody else who sees the failure with -jN,
N>1) try a bootstrap on x86_64-apple-darwin10 with non-parallel make from a
clean directory?

If that fails, that would be a pretty clear indication that this bug has
nothing to do with make parallelism.  (There are lots of other reasons why
bootstrap comparisons can fail, some of which are quite system-dependent, so a
builds on darwin9 and on darwin10 may not both expose the issue.)


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

--- Comment #10 from dominiq at lps dot ens dot fr  2010-02-28 12:32 ---
(In reply to comment #8)
> Thank you, very well.  Can you (or somebody else who sees the failure with 
> -jN,
> N>1) try a bootstrap on x86_64-apple-darwin10 with non-parallel make from a
> clean directory?

I don't understand what you are expecting. Since the parallel bootstrap works
most of the time, why are you expecting the non-parallel one to always fail? It
seems to me highly unlikely. Note that a bootstrap with only gcc and gfortran
takes about 1 hour in parallel, so probably ~2 hours in non-parallel.


-- 


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

[Bug tree-optimization/43209] New: ICE in try_improve_iv_set, at tree-ssa-loop-ivopts.c:5238

[zsojka at seznam dot cz]

Command line:
gcc -O1 testcase.c
(fails at all -O[123] levels)

Tested revisions:
r156999 - crash
r156745 - crash
r156293 - OK
4.4 r156256 - OK (with checking)

Output (with checking):
$ mnt/svn/gcc-trunk/binary-156999-lto/bin/gcc -O1 testcase.c
testcase.c: In function 'foo':
testcase.c:1:6: internal compiler error: in try_improve_iv_set, at
tree-ssa-loop-ivopts.c:5238
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Output (without checking):
$ gcc-4.5.0-alpha20100225 -O1 testcase.c
testcase.c: In function 'foo':
testcase.c:1:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE in try_improve_iv_set, at tree-ssa-loop-
ivopts.c:5238
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug tree-optimization/43209] ICE in try_improve_iv_set, at tree-ssa-loop-ivopts.c:5238

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-02-28 13:42 ---
Created an attachment (id=19986)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19986&action=view)
reduced testcase

Command line:
gcc -O1 pr43209.c
(or -O2, -O3)


-- 


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

[Bug fortran/43180] [4.5 Regression] Bad results without temporary copy of intent(in) argument

[pault at gcc dot gnu dot org]

--- Comment #10 from pault at gcc dot gnu dot org  2010-02-28 13:46 ---
(In reply to comment #9)
> Reduced test case below. The problem is the call. On the trunk the call looks
> as follows:
>   set_set_v (&ru, D.1578);
> which is complete nonesense. It should be:
>   &ru.data[0].c.use
> or something like that. If one removes the "comment" component, it works - but
> only because then "&ru" and "&ru.data[0].c.use" point to the same memory -
> otherwise it is as wrong as before.

Yes, indeed - that is the problem.  Since the need for a temporary has been
removed, the code now runs straight into line trans-array.c:5515.  The
condition !sym->as causes tmp to be used as the actual, rather than calling
gfc_conv_expr_descriptor.

Just as soon as todayś clean build stops, I will remove the condition and will
try a regtest.

Paul


-- 


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

[Bug tree-optimization/43209] [4.5 Regression] ICE in try_improve_iv_set, at tree-ssa-loop-ivopts.c:5238

[zsojka at seznam dot cz]

--- Comment #2 from zsojka at seznam dot cz  2010-02-28 13:49 ---
4.4 r157120 works fine too

testcase doesn't fail at -O2, -O3 (in trunk)


-- 

zsojka at seznam dot cz changed:

   What|Removed |Added

  Known to fail||4.5.0
  Known to work||4.4.3
Summary|ICE in try_improve_iv_set,  |[4.5 Regression] ICE in
   |at tree-ssa-loop-   |try_improve_iv_set, at tree-
   |ivopts.c:5238   |ssa-loop-ivopts.c:5238


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

[Bug fortran/43210] New: Initializer of huge static arrays should be improved

[burnus at gcc dot gnu dot org]

Follow up to PR 43205

subroutine test()
  integer, SAVE :: hugeArray(1000,1000) = 42

generates a huge initializer of the type:

  static integer(kind=4) hugeArray = {42, 42, 42, , 42};

It would be possible to reduce the compile time and object size by initializing
it a run time:

  static integer(kind=4) hugeArray;
  static logical initialized = false
  if (!initialized)
{
  initialized = true
  for(i=0, i < size; i++) hugeArray = 42;
}

The question is only how big the array should be. I think one common case of
this could also be  -finit-integer=42.


-- 
   Summary: Initializer of huge static arrays should be improved
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/43205] -finit-local-zero and -fno-automatic used together with large 2-dim variables take too long to compile

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-02-28 14:05 ---
CONFIRMED. For zero initialization, the created dump should look like:
  static integer(kind=4) variable(10) = {};
rather than
  static integer(kind=4) variable(10) = {0,0,0,0,0,0,,0,0};

I think as workaround one can simply leave out the -finit-local-zero as static
variables are always zero initialized. And with -fno-automatic one should only
have static variables.

 * * *

For the example in comment 1: This is not a real regression as before the data
was not properly handled. I filled now PR 43210, which is one way out. (Thanks
Dominique for the suggestion.)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-28 14:05:21
   date||


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

[Bug c/43211] New: [4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1430

[zsojka at seznam dot cz]

Command line:
gcc testcase.c

Tested revisions:
r156999 - crash
r155363 - crash
r153685 - crash
4.4 r157120 - OK (with checking)
4.3.4 - OK (without checking)

Output (with checking):
$ /mnt/svn/gcc-trunk/binary-156999-lto/bin/gcc testcase.c
testcase.c:7:19: error: parameter 1 ('t') has incomplete type
testcase.c: In function 'foo':
testcase.c:11:10: internal compiler error: tree check: expected class 'type',
have 'exceptional' (error_mark) in useless_type_conversion_p, at
tree-ssa.c:1430
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Output (without checking):
$ gcc-4.5.0-alpha20100225 testcase.c
testcase.c:7:19: error: parameter 1 ('t') has incomplete type
testcase.c:11: confused by earlier errors, bailing out

I don't know how much is this related to pr43082


-- 
   Summary: [4.5 Regression] ICE: tree check: expected class 'type',
have 'exceptional' (error_mark) in
useless_type_conversion_p, at tree-ssa.c:1430
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug c/43211] [4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1430

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-02-28 14:15 ---
Created an attachment (id=19987)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19987&action=view)
reduced testcase

Command line:
gcc pr43211.c


-- 


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

[Bug fortran/43210] Initializer of huge static arrays should be improved

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-02-28 15:02 ---
A bonus: There should be only a single "logical initialized" variable for all
initializers.


-- 


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

[Bug fortran/42912] BLOCK: C1278 - wrongly accepts SAVE in pure procedure

[domob at gcc dot gnu dot org]

--- Comment #2 from domob at gcc dot gnu dot org  2010-02-28 15:07 ---


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


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/43169] [OOP] gfortran rejects pure procedure with select type construct

[domob at gcc dot gnu dot org]

--- Comment #8 from domob at gcc dot gnu dot org  2010-02-28 15:07 ---
*** Bug 42912 has been marked as a duplicate of this bug. ***


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


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

[Bug lto/43212] New: [LTO] error: control flow in the middle of basic block

[d dot g dot gorbachev at gmail dot com]

 1.c 
extern void baz(void);

void foo(void)
{
  baz();
}
 2.c 
extern __attribute__((__noreturn__)) void baz(void);

void bar(void)
{
  baz();
}
=
$ gcc -r -nostdlib -O2 -flto 1.c 2.c

In file included from :0:0:
1.c: In function 'foo':
1.c:3:6: error: control flow in the middle of basic block 2
1.c:3:6: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /usr/local/bin/i686-pc-linux-gnu-gcc-4.5.0 returned 1 exit status
collect2: lto-wrapper returned 1 exit status


-- 
   Summary: [LTO] error: control flow in the middle of basic block
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot g dot gorbachev at gmail dot com
 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=43212

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

--- Comment #11 from dominiq at lps dot ens dot fr  2010-02-28 15:39 ---
I just completed successfully a clean non-parallel bootstrap at revision 157122
with

../p_work/configure --prefix=/opt/gcc/gcc4.5p
--mandir=/opt/gcc/gcc4.5p/share/man --infodir=/opt/gcc/gcc4.5p/share/info
--build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10
--target=x86_64-apple-darwin10 --enable-languages=c,fortran
--with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--with-cloog=/opt/sw64 --with-ppl=/opt/sw64 --with-mpc=/opt/sw64


-- 


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

[Bug fortran/43205] -finit-local-zero and -fno-automatic used together with large 2-dim variables take too long to compile

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2010-02-28 16:16 ---
Subject: Bug 43205

Author: burnus
Date: Sun Feb 28 16:16:22 2010
New Revision: 157123

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157123
Log:
2010-02-28  Tobias Burnus  

PR fortran/43205
* trans-expr.c (is_zero_initializer_p): Move up in the file.
(gfc_conv_initializer): Handle zero initializer as special case.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c


-- 


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

[Bug tree-optimization/43209] [4.5 Regression] ICE in try_improve_iv_set, at tree-ssa-loop-ivopts.c:5238

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2010-02-28 17:02 ---
It is caused by revision 156701:

http://gcc.gnu.org/ml/gcc-cvs/2010-02/msg00283.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||spop at gcc dot gnu dot org


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

[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers

[mmitchel at gcc dot gnu dot org]

--- Comment #22 from mmitchel at gcc dot gnu dot org  2010-02-28 17:08 
---
Subject: Bug 42748

Author: mmitchel
Date: Sun Feb 28 17:07:54 2010
New Revision: 157124

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157124
Log:
2010-02-27  Mark Mitchell  

PR c++/42748
* cp-tree.h (push_tinst_level): Declare.
(pop_tinst_level): Likewise.
* pt.c (push_tinst_level): Give it external linkage.
(pop_tinst_level): Likewise.
* mangle.c (mangle_decl_string): Set the source location to that
of the decl while mangling.

2010-02-27  Mark Mitchell  

PR c++/42748
* g++.dg/abi/mangle11.C: Adjust mangling warning locations.
* g++.dg/abi/mangle12.C: Likewise.
* g++.dg/abi/mangle20-2.C: Likewise.
* g++.dg/abi/mangle17.C: Likewise.
* g++.dg/template/cond2.C: Likewise.
* g++.dg/template/pr35240.C: Likewise.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/mangle.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/abi/mangle11.C
trunk/gcc/testsuite/g++.dg/abi/mangle12.C
trunk/gcc/testsuite/g++.dg/abi/mangle17.C
trunk/gcc/testsuite/g++.dg/abi/mangle20-2.C
trunk/gcc/testsuite/g++.dg/template/cond2.C
trunk/gcc/testsuite/g++.dg/template/pr35240.C


-- 


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

[Bug fortran/43205] -finit-local-zero and -fno-automatic used together with large 2-dim variables take too long to compile

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2010-02-28 17:16 ---
FIXED on the trunk (for zero initialization). Thanks for the report! Here, the
example of comment 0 now compiles in 0.037s.

Regarding non-zero initialization (cf. comment 1), see follow-up PR 43210.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/43178] Pointless resetting to NULL for local ALLOCATABLEs

[burnus at gcc dot gnu dot org]

--- Comment #14 from burnus at gcc dot gnu dot org  2010-02-28 17:30 ---
Created an attachment (id=19988)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19988&action=view)
Another update - handle -fno-automatic & fixes ICE in comment #11

Fixes ICE in comment #11, handles STATIC implied by -fno-automatic.

Regarding "no_free" -> "dealloc": The change was done because "!no_free" (read:
"no(t) no_free" sounds awkward. no-dealloc(ate) sounds better, albeit not much.
And unfortunately, the compiler cannot compile-time diagnose such
inconsistencies in comments ;-)  (Now fixed.)

Regarding the failure in comment #13: I missed a check for -fno-automatic,
which also implies SAVE; this is now fixed. Regarding the (de|in)creased
compile time: This is unavoidable in the current implementation, see PR 43210
for a possible fix.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #19972|0   |1
is obsolete||


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

[Bug fortran/42950] gfortran testsuite failures on mingw64

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2010-02-28 17:42 ---
Patch for using _POSIX - untested.

Index: libgfortran/io/io.h
===
--- libgfortran/io/io.h (Revision 157097)
+++ libgfortran/io/io.h (Arbeitskopie)
@@ -27,6 +27,12 @@
 #ifndef GFOR_IO_H
 #define GFOR_IO_H

+/* Ensure that ANSI conform stdio is used. This needs to be set before
+   any system header file is included.  */
+#if defined __MINGW32__
+#  define _POSIX 1
+#endif
+
 /* IO library include.  */

 #include "libgfortran.h"


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[rwild at gcc dot gnu dot org]

--- Comment #12 from rwild at gcc dot gnu dot org  2010-02-28 18:14 ---
Thanks.  You are right that the chance for a non-parallelism-related failure
was low, but comparison failures can be due to the phase of the moon literally.

Anyway, here's how I usually debug parallel build failures: rebuild until you
have both a successful and failed build, moving prior build trees away like:
  for i in 1 2 3 4; do
mv build build-$i && mkdir build && cd build &&
../gcc/configure ... && make -jN
  done

That way one can compare the trees afterward without spurious path name diffs.

Compare the contents of build-$i/stage-{1,2,3}-$host/libgomp with that of a bad
build and in between the three stages.  Esp. the libgomp/.deps subdirs and the
config.log and config.status files.  Chances are you will find suspect issues
even when looking only at those of the different stages of a single build.

If that all doesn't lead anywhere, then posting the output from a failed build
would be a good idea.  Sorry I can't help better.


-- 


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

[Bug fortran/43178] Pointless resetting to NULL for local ALLOCATABLEs

[burnus at gcc dot gnu dot org]

--- Comment #15 from burnus at gcc dot gnu dot org  2010-02-28 19:48 ---
Created an attachment (id=19989)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19989&action=view)
Really fix -fno-automatic -- attached the wrong patch which missed a "== 0" in
trans-decl.

As pointed out by Dominique. Next step is to proofread the patch, check the
"dealloc" argument and check for run-time leakage of the testsuite's "dg-do
run" tests. Re-checking some dumps cannot harm either.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #19988|0   |1
is obsolete||


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

[Bug tree-optimization/43213] New: [4.5 Regression] Worse code generated with -O2

[d dot g dot gorbachev at gmail dot com]

-- 
   Summary: [4.5 Regression] Worse code generated with -O2
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot g dot gorbachev at gmail dot com
 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=43213

[Bug tree-optimization/43213] [4.5 Regression] Worse code generated with -O2

[d dot g dot gorbachev at gmail dot com]

--- Comment #1 from d dot g dot gorbachev at gmail dot com  2010-02-28 
19:57 ---
Created an attachment (id=19990)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19990&action=view)
Poor code


-- 


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

[Bug tree-optimization/43213] [4.5 Regression] Worse code generated with -O2

[d dot g dot gorbachev at gmail dot com]

--- Comment #2 from d dot g dot gorbachev at gmail dot com  2010-02-28 
19:58 ---
Created an attachment (id=19991)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19991&action=view)
C source


-- 


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

[Bug preprocessor/43195] #pragma once and -H

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2010-02-28 20:12 ---
Approved patch http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01246.html


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||41998
  nThis||


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

[Bug fortran/43214] New: [OOP] TBP with non-scalar PASS

[burnus at gcc dot gnu dot org]

I think there was not yet a PR about this. The following program compiles with
NAG f95 but fails in gfortran with:

call x(:)%foo
  1
Error: Non-scalar base object at (1) currently not implemented


module m
type t
contains
  procedure, pass :: foo => foo
end type t
contains
  elemental subroutine foo(x)
class(t),intent(in) :: x
  end subroutine foo
end module m

use m
type(t) :: x(3)
call x(:)%foo
end


-- 
   Summary: [OOP] TBP with non-scalar PASS
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug tree-optimization/43209] [4.5 Regression] ICE in try_improve_iv_set, at tree-ssa-loop-ivopts.c:5238

[amonakov at gcc dot gnu dot org]

--- Comment #4 from amonakov at gcc dot gnu dot org  2010-02-28 22:01 
---
Confirmed.
The first invocation of get_computation_aff fails with ustep == (long) j, cstep
== (unsigned long) j: constant_multiple_of (ustep, cstep, &rat) returns false
(j is int, STRIP_NOPS ({u,c}step) preserves conversions).


-- 

amonakov at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-28 22:01:43
   date||


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

[Bug fortran/43207] [OOP] ICE for invalid pointer assignment => type%parent

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-02-28 22:29 ---
(In reply to comment #1)
> It boils down to understand what makes data-ref polymorphic

Answer: "A polymorphic entity is a data entity that is able to be of differing
types during program execution." (F2003, "5.1.1.2 CLASS")

Thus "somethings%class" is valid as this entity can have different types; by
contrast, "class%non_class" is not polymorphic as the last part-ref is always
of the type of non_class.

 * * *

Thus, one needs to reject:
  ptr => abstract_non_polymorph
  abstract_non_polymorph = something
  something = abstract_non_polymorph
  call fooBar(abstract_non_polymorph)
which can presumably best be done in gfc_match_varspec.


-- 


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

[Bug tree-optimization/43209] [4.5 Regression] ICE in try_improve_iv_set, at tree-ssa-loop-ivopts.c:5238

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug testsuite/40459] g++.dg/abi/mangle*.C fail on darwin

[mikestump at comcast dot net]

--- Comment #13 from mikestump at comcast dot net  2010-03-01 00:23 ---
This is a dup of c++/42748, which has now been fixed.


-- 


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

[Bug testsuite/42308] test-demangle, test-pexecute and test-expandargv compiled with wrong compiler

[howarth at nitro dot med dot uc dot edu]

--- Comment #1 from howarth at nitro dot med dot uc dot edu  2010-03-01 
01:11 ---
This also happens for i686-apple-darwin10

make[2]: Nothing to be done for `check'.
gcc -DHAVE_CONFIG_H -g -O2 -I..
-I../../../gcc-4.5-20100228/libiberty/testsuite/../../include  -o test-demangle
\
../../../gcc-4.5-20100228/libiberty/testsuite/test-demangle.c
../libiberty.a
ld: warning: in ../libiberty.a, file is not of required architecture
Undefined symbols:
  "_is_gnu_v3_mangled_dtor", referenced from:
  _main in cca5XU3G.o
  "_is_gnu_v3_mangled_ctor", referenced from:
  _main in cca5XU3G.o
  "_cplus_demangle_set_style", referenced from:
  _main in cca5XU3G.o
  _main in cca5XU3G.o
  "_xmalloc", referenced from:
  _get_line in cca5XU3G.o
  "_cplus_demangle_name_to_style", referenced from:
  _main in cca5XU3G.o
  _main in cca5XU3G.o
  "_xrealloc", referenced from:
  _get_line in cca5XU3G.o
  "_cplus_demangle", referenced from:
  _main in cca5XU3G.o
  _main in cca5XU3G.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[3]: *** [test-demangle] Error 1
gcc -DHAVE_CONFIG_H -g -O2 -I..
-I../../../gcc-4.5-20100228/libiberty/testsuite/../../include  -DHAVE_CONFIG_H
-I.. -o test-pexecute \
../../../gcc-4.5-20100228/libiberty/testsuite/test-pexecute.c
../libiberty.a
ld: warning: in ../libiberty.a, file is not of required architecture
Undefined symbols:
  "_pexecute", referenced from:
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  "_pex_init", referenced from:
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  "_pex_get_status", referenced from:
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  "_pex_read_output", referenced from:
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  "_pex_run", referenced from:
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  "_pex_free", referenced from:
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
  "_xstrerror", referenced from:
  _fatal_error in ccp2aaPu.o
  "_pwait", referenced from:
  _main in ccp2aaPu.o
  _main in ccp2aaPu.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[3]: *** [test-pexecute] Error 1
gcc -DHAVE_CONFIG_H -g -O2 -I..
-I../../../gcc-4.5-20100228/libiberty/testsuite/../../include  -DHAVE_CONFIG_H
-I.. -o test-expandargv \
../../../gcc-4.5-20100228/libiberty/testsuite/test-expandargv.c
../libiberty.a
ld: warning: in ../libiberty.a, file is not of required architecture
Undefined symbols:
  "_dupargv", referenced from:
  _run_tests in cc9bX5PF.o
  _run_tests in cc9bX5PF.o
  "_expandargv", referenced from:
  _run_tests in cc9bX5PF.o
  "_xstrerror", referenced from:
  _fatal_error in cc9bX5PF.o
  "_freeargv", referenced from:
  _run_tests in cc9bX5PF.o
  _run_tests in cc9bX5PF.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[3]: *** [test-expandargv] Error 1
make[3]: Target `check' not remade because of errors.
make[2]: *** [check-subdir] Error 2
make[2]: Target `check' not remade because of errors.
make[1]: *** [check-libiberty] Error 2
make[1]: Target `check-host' not remade because of errors.

because the system compiler defaults to -m64 and the built compiler to -m32
causing the mismatch.


-- 


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

[Bug target/43215] New: x86-64: Nonstandard instruction "movd %xmm0, %rax"

[richardpku at gmail dot com]

#include 
uint64_t extract_double (double x)
{
union {
double dbl;
uint64_t u;
} t;
t.dbl = x;
return t.u;
}

Compile this function with "x86_64-pc-linux-gnu-gcc -O2 -march=core2 -S a.c",
and we get the following assembly codes:

extract_double:
.LFB0:
.cfi_startproc
movd%xmm0, %rax
ret

The instruction "movd %xmm0, %rax" is nonstandard. Movd should be replaced by
movq.

(GNU assembler silently accepts it as if it were "movq %xmm0, %rax", so it
probably has caused no practical problems.)


-- 
   Summary: x86-64: Nonstandard instruction "movd %xmm0, %rax"
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: richardpku at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: i686-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug testsuite/42308] test-demangle, test-pexecute and test-expandargv compiled with wrong compiler

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2010-03-01 
04:49 ---
Created an attachment (id=19992)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19992&action=view)
Makefile from darwin_objdir/libiberty with commented line that eliminates the
bug


-- 


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

[Bug testsuite/42308] test-demangle, test-pexecute and test-expandargv compiled with wrong compiler

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2010-03-01 
04:52 ---
I find that for i686-apple-darwin10, if I comment the line...

# Flags to pass to a recursive make.
FLAGS_TO_PASS = \
"AR=$(AR)" \
"AR_FLAGS=$(AR_FLAGS)" \
#   "CC=$(CC)" \
"CFLAGS=$(CFLAGS)" \

in the  darwin_objdir/libiberty/Makefile, then 'make -k check-libiberty'
executed at the toplevel of darwin_objdir compiles without error.


-- 


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

[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2010-03-01 06:30 
---
Created an attachment (id=19993)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19993&action=view)
A suggested patch

This patch does the trick.  I think it is sensible to not warn on leading
spaces, a comment, or continuation &.


-- 


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

[Bug testsuite/42308] test-demangle, test-pexecute and test-expandargv compiled with wrong compiler

[ghazi at gcc dot gnu dot org]

--- Comment #4 from ghazi at gcc dot gnu dot org  2010-03-01 07:15 ---
Is this a dup of 29404 ?


-- 


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

[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2010-03-01 07:31 ---
(In reply to comment #5)
> Created an attachment (id=19993)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19993&action=view) [edit]
> A suggested patch
> 
> This patch does the trick.  I think it is sensible to not warn on leading
> spaces, a comment, or continuation &.

I agree, however, I would expect still a warning for
  something  & dhjgjl
where "&" is e.g. in column 73.

 * * *

Something related: In free format, there is no trunction warning for
 print *, 'Hello '  // 'world'
even though only "Hello" is printed. That is a 4.5 regression.


-- 


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

[Bug fortran/43214] [OOP] TBP with non-scalar PASS

[domob at gcc dot gnu dot org]

--- Comment #1 from domob at gcc dot gnu dot org  2010-03-01 07:48 ---
This is mentioned as still missing in PR 41177 which I kept open for that, but
it's probably really a good idea to have a new PR.  I'll close 41177 instead,
referring here.  Note that there might be some infos and especially one
test-case in PR 41177.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||domob at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-01 07:48:26
   date||


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

[Bug fortran/41177] Wrong base-object checks for type-bound procedures

[domob at gcc dot gnu dot org]

--- Comment #8 from domob at gcc dot gnu dot org  2010-03-01 07:49 ---
Closing, the missing part has its own PR 43214 now (which I think is a good
idea).


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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