[Bug target/36399] ABI bug on darwin/x86-32

[howarth at nitro dot med dot uc dot edu]

--- Comment #11 from howarth at nitro dot med dot uc dot edu  2010-03-12 
04:06 ---
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00472.html.


-- 


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

[Bug c/16602] Spurious warnings about pointer to array -> const pointer to array conversion

[ilatypov at infradead dot org]

--- Comment #9 from ilatypov at infradead dot org  2010-03-12 03:49 ---
(In reply to comment #7)
> I am reopening the bug cause I still don't have a clue why "pointer to array 
> of
> ints" typed expression is assignment incompatible with a "pointer to array of
> const ints" typed lvalue. Especially when "pointer to int" typed expression IS
> assignment compatible with "pointer to const int" typed lvalue. This is what 
> is
> this bug all about.

Comment #9 to bug 33076 showed me a link explaining how constness of a multiply
referenced value cannot be promised, and, therefore, C propagates the compile
-time constness requirement up the assignment chain in cases where the level of
pointer indirection is greater than 1.  

  http://c-faq.com/ansi/constmismatch.html

I came up with a similar example for the "array of const ints".   It shows that
the const promise might have been violated inside the function if
multiply-indirected lvalue constness was relaxed.

typedef const int carr_t[8];
typedef int arr_t[8];

void foo(carr_t *carrp) {
arr_t *hacker;
carr_t **holder = &hacker;  // a warning

(*holder) = carrp;  // "hacker = carrp" in disguise, but both sides are
(carr_t *)

(*hacker)[ 0 ] = 9; // no warning
}

void bar(void) {
arr_t arr = { 1, 2, 3, 4, 5, 6, 7, 8 };
foo(arr);   // a warning
}


-- 

ilatypov at infradead dot org changed:

   What|Removed |Added

 CC||ilatypov at infradead dot
   ||org


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

[Bug c++/43333] [4.5 Regression] __is_pod seems broken

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-03-12 02:36:38 |2010-03-12 02:55:29
   date||


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

[Bug c++/43333] [4.5 Regression] __is_pod seems broken

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2010-03-12 02:48 ---
strPOD isn't trivial; its copy assignment operator is ill-formed/deleted.  This
is a change in PODness between C++98 and C++0x which may not have been
intended.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|jason at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW


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

[Bug c++/43333] [4.5 Regression] __is_pod seems broken

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-03-11 16:24:31 |2010-03-12 02:36:38
   date||


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

[Bug c/40989] -Werror= and #pragma diagnostics do not work with group flags

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2010-03-12 00:15 ---
Created an attachment (id=20091)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20091&action=view)
patch

This is my current patch to fix this. However, it has a big problem: Since
there is no "namespace" for options (all options are visible from everywhere),
functions referenced in options.h must be defined in a file that is linked with
everything, which is very inconvenient. Any ideas how to overcome this?


-- 


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

[Bug fortran/43339] New: Incorrect output for pgm checking data sharing attributes

[longb at cray dot com]

In this case the variable i should be shared except in the task
construct that contains the do loop on i.

Test case:

program F03_2_9_1_1_5a
   use omp_lib
   implicit none
   integer, parameter :: NT = 4
   integer, parameter :: EXPECTED_RESULT = -1 ! expected value of i at end
   integer :: dummy_var, i = EXPECTED_RESULT

   call omp_set_dynamic(.false.)
   call omp_set_num_threads(NT)

!$omp parallel
   !$omp single
   !$omp task
  !$omp task
  ! i should be private in this task region (OMP 3.0, [78:26-27])
 do i = 1,NT 
dummy_var = omp_get_thread_num() ! give the loop something to do
 end do
  !$omp end task

  !$omp taskwait ! wait for the explicit task to finish

  ! i should be shared in this task region (OMP 3.0, [79:31-33])
  if (i /= EXPECTED_RESULT) then
print *, 'FAIL (in task construct) - i == ', i , ' (expected ', &
  EXPECTED_RESULT, ')'
  end if
   !$omp end task
   !$omp end single ! implicit barrier ensures all tasks have finished

   ! i should be shared in this parallel region (OMP 3.0, [79:27-28])
   if (i /= EXPECTED_RESULT) then
  print *, 'FAIL (in parallel construct) - i == ', i , ' (expected ', &
   EXPECTED_RESULT, ')'
   end if
!$omp end parallel

end program F03_2_9_1_1_5a

> gfortran -fopenmp test.f90
> ./a.out
 FAIL (in task construct) - i ==0  (expected   -1 )
 FAIL (in parallel construct) - i ==32767  (expected   -1 )
 FAIL (in parallel construct) - i ==0  (expected   -1 )
 FAIL (in parallel construct) - i ==0  (expected   -1 )
 FAIL (in parallel construct) - i ==10941  (expected   -1 )


-- 
   Summary: Incorrect output for pgm checking data sharing
attributes
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
 GCC build triplet: x86_64-suse-linux
  GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux


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

[Bug fortran/43338] New: ICE: in single_pred_edge, at basic-block.h:658

[longb at cray dot com]

Test case:

program F03_2_9_3_5_2b
   use omp_lib
   implicit none
   integer, parameter :: NT = 4
   integer, parameter :: int64_t = selected_int_kind(18)
   integer (kind=int64_t), parameter::DYNAMIC_MEMORY = 536870912_int64_t
!512MiB
   integer (kind=int64_t), parameter::ARRAY_SIZE = DYNAMIC_MEMORY/NT/8
   integer, parameter :: EXPECTED_RESULT = 1
   logical :: fail = .false.
   integer :: i
   integer (kind=int64_t), allocatable :: A(:)

   call omp_set_num_threads(NT)
   call omp_set_dynamic(.false.)

   !$omp parallel
  if (omp_get_thread_num() == NT-1) then
 allocate(A(ARRAY_SIZE))
  end if

  !$omp barrier! ensure A is allocated before the sections region

  !$omp sections lastprivate(A)
 ! This thread sleeps to attempt to let the thread that executes the
 ! next section get ahead.
 call sleep(5)
 A = EXPECTED_RESULT+1
 !$omp section
 A = EXPECTED_RESULT
  !$omp end sections ! implicit barrier at end of sections construct
  !$omp master
  ! verify that all elements of the array are EXPECTED_RESULT
  if (MAXVAL(A) /= EXPECTED_RESULT .or. MINVAL(A) /= EXPECTED_RESULT) then
 print *, 'FAIL - MAXVAL(A) == ', MAXVAL(A), ' (expected ', &
  EXPECTED_RESULT, '), MINVAL(A) == ', MINVAL(A), &
  ' (expected ', EXPECTED_RESULT, ')'
 stop 1
  end if
  !$omp end master
   !$omp end parallel

end program F03_2_9_3_5_2b

Compilation:

> gfortran -c -fopenmp test.f90
test.f90: In function 'f03_2_9_3_5_2b':
test.f90:25: internal compiler error: in single_pred_edge, at basic-block.h:658
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE:  in single_pred_edge, at basic-block.h:658
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
 GCC build triplet: x86_64-suse-linux
  GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux


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

[Bug fortran/43337] New: ICE: in lookup_decl_in_outer_ctx, at omp-low.c:2103

[longb at cray dot com]

Test case:

program F03_2_9_1_1_2b
   use omp_lib
   implicit none
   integer, parameter :: NT = 4
   integer :: explicit_shape_array(NT,0:NT-1) = -1 ! invalid value
   integer :: row, thread_num

   call omp_set_dynamic(.false.)
   call omp_set_num_threads(NT)

   call test_assumed_size_array(explicit_shape_array, &
size(explicit_shape_array,1))

   do thread_num = 0, NT-1
  do row = 1, NT
 if (explicit_shape_array(row, thread_num) /= thread_num) then
print *, 'FAIL - explicit_shape_array(', row, &
 ',', thread_num,')',&
 ') == ', explicit_shape_array(row, thread_num), &
 ' (expected ', row, ')'
 stop 1
 end if
  end do
   end do

contains
   subroutine test_assumed_size_array(assumed_size_array, dim1)
  use omp_lib
  implicit none
  integer :: dim1, assumed_size_array(dim1,0:*) ! size is dim1*dim1
  integer :: i
!$omp parallel
!$omp task if (.false.) shared(assumed_size_array)
  do row = 1, dim1 !"row" predetermined shared per 
   ! OpenMP 3.0 p. 78 l.26-27
 assumed_size_array(row, omp_get_thread_num())= omp_get_thread_num()
  end do
!$omp end task
!$omp end parallel
   end subroutine test_assumed_size_array
end program F03_2_9_1_1_2b


Compilation:

> gfortran -fopenmp test.f90
test.f90: In function 'test_assumed_size_array':
test.f90:35: internal compiler error: in lookup_decl_in_outer_ctx, at
omp-low.c:2103
Please submit a full bug report,
with preprocessed source if appropriate.


Workaround:

In the contained routine, declare the variable row locally:

<   integer :: i
---
>   integer :: i, row


-- 
   Summary: ICE: in lookup_decl_in_outer_ctx, at omp-low.c:2103
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
 GCC build triplet: x86_64-suse-linux
  GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux


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

[Bug tree-optimization/43257] [4.5 Regression] IPA-SRA changes DECL_ASSEMBLER_NAME

[jamborm at gcc dot gnu dot org]

--- Comment #4 from jamborm at gcc dot gnu dot org  2010-03-11 22:39 ---
Fixed.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/43257] [4.5 Regression] IPA-SRA changes DECL_ASSEMBLER_NAME

[jamborm at gcc dot gnu dot org]

--- Comment #3 from jamborm at gcc dot gnu dot org  2010-03-11 22:27 ---
Subject: Bug 43257

Author: jamborm
Date: Thu Mar 11 22:27:26 2010
New Revision: 157393

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157393
Log:
2010-03-11  Martin Jambor  

PR tree-optimization/43257
* tree.c (assign_assembler_name_if_neeeded): New function.
(free_lang_data_in_cgraph): Assembler name assignment moved to the
above new function.
* tree.h (assign_assembler_name_if_neeeded): Declare.
* cgraphunit.c (cgraph_analyze_function): Create an assembler name for
the function if needed.

* testsuite/g++.dg/torture/pr43257.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/torture/pr43257.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h


-- 


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

[Bug inline-asm/41538] Mixing ARM/NEON intrinsic variables and inline assembly

[gmcgrath at yahoo dot com]

--- Comment #4 from gmcgrath at yahoo dot com  2010-03-11 21:48 ---
Bug 37188 answers half the problem.  It still does not answer why:

   register int16x8_t val asm ("q0");

compiles without warning yet does not put "val" into the "q0" NEON register. 


-- 

gmcgrath at yahoo dot com changed:

   What|Removed |Added

 CC||gmcgrath at yahoo dot com
 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/43333] [4.5 Regression] __is_pod seems broken

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2010-03-11 21:12 ---
It is caused by revision 149721:

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


-- 


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

[Bug driver/43334] Generate an XML dump of the parse tree

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2010-03-11 21:10 ---
James, you probably can implement this as a GCC plugin, not native or forked
GCC needed, as Andrew said. 

But, in any case, you should seek developers from outside the core GCC for your
project (and if possible, bring them closer to GCC), because core GCC
developers are already overworked with ongoing projects and this, as far as I
know, is not an interesting feature for them.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug inline-asm/41538] Mixing ARM/NEON intrinsic variables and inline assembly

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-03-11 20:32 ---
(In reply to comment #2)
> When documentation is missing the needed bits information, these can be
> typically extracted from the source code.
> 
> The only problem is that these constraints can be changed any time without
> notice unless properly documented and exposed to the outside world. There is
> bug 37188 about it.

That is about the modifiers rather the constraints.  Anyways w is the correct
constraints here.  Closing as invalid.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug inline-asm/41538] Mixing ARM/NEON intrinsic variables and inline assembly

[siarhei dot siamashka at gmail dot com]

--- Comment #2 from siarhei dot siamashka at gmail dot com  2010-03-11 
20:29 ---
When documentation is missing the needed bits information, these can be
typically extracted from the source code.

The only problem is that these constraints can be changed any time without
notice unless properly documented and exposed to the outside world. There is
bug 37188 about it.


-- 

siarhei dot siamashka at gmail dot com changed:

   What|Removed |Added

 CC||siarhei dot siamashka at
   ||gmail dot com


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

[Bug middle-end/42431] [4.5 Regression] wrong code for 200.sixtrack with vectorization and -fdata-sections

[meissner at gcc dot gnu dot org]

--- Comment #14 from meissner at gcc dot gnu dot org  2010-03-11 20:11 
---
Created an attachment (id=20090)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20090&action=view)
Patch to remove band-aid now that the underlying problem was fixed

In doing the initial VSX development, I ran into a situation in building spec
2006, that ultimately was caused by the bug in 42431.  I added some band-aid
code to make sure the problem was not seen.  After Jeff's patches were checked
in, I deleted the code, and built spec 2006 with several different options, and
the code built/ran correctly.  So this is no longer needed.


-- 


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

[Bug other/43336] GCC leaves a temporary LTO output file in $TMPDIR

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-03-11 20:06 ---
*** Bug 41931 has been marked as a duplicate of this bug. ***


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


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

[Bug driver/41931] -fuse-linker-plugin leaves temporary file behind

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-03-11 20:06 ---


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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug debug/42959] g++ does not emit DW_AT_default_value

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-03-11 20:01 ---
I think instead of creating the _1 functions you should just add the attr
argument to those 2 functions and modify callers to pass DW_AT_const_value.
There aren't so many callers, and
add_location_or_const_value_attribute/add_AT_location_description is an example
already.  Perhaps putting attr argument right after die would be better too.


-- 


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

[Bug fortran/43228] NAMELIST I/O: Reading at 2 dimensions (rank) array values.

[burnus at gcc dot gnu dot org]

--- Comment #18 from burnus at gcc dot gnu dot org  2010-03-11 19:48 ---
Close as FIXED. Thanks for the bugreport!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/43228] NAMELIST I/O: Reading at 2 dimensions (rank) array values.

[burnus at gcc dot gnu dot org]

--- Comment #17 from burnus at gcc dot gnu dot org  2010-03-11 19:48 ---
Subject: Bug 43228

Author: burnus
Date: Thu Mar 11 19:48:11 2010
New Revision: 157391

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157391
Log:
2010-03-11  Tobias Burnus  

PR fortran/43228
* io/list_read.c (nml_parse_qualifier): Disable expanded_read
for array sections.

2010-03-11  Tobias Burnus  

PR fortran/43228
* gfortran.dg/namelist_61.f90: New test.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/namelist_61.f90
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/libgfortran/ChangeLog
branches/gcc-4_4-branch/libgfortran/io/list_read.c


-- 


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

[Bug bootstrap/43328] multilib bootstrap broken.

[pluto at agmk dot net]

--- Comment #11 from pluto at agmk dot net  2010-03-11 19:33 ---
(In reply to comment #8)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew?
> > 
> > no, what for? svn status reports no unversioned files in trunk directory.
> 
> Please allow me to be dense, and ask you to *please* rm -rf the source
> tree and check it out anew.  Just do it. And then, when your build still
> fails, report the revision you're building, the exact configure command
> line you've used, and the error that you get, starting from the *first*
> error message, not the last one.  Thanks.

'rm -rf' done, checkout done, 'svn pd svn:ignore trunk -R' done,
build log attached, build script attached, 'svn st' reports clean
source tree.


-- 


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

[Bug bootstrap/43328] multilib bootstrap broken.

[pluto at agmk dot net]

--- Comment #10 from pluto at agmk dot net  2010-03-11 19:29 ---
Created an attachment (id=20089)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20089&action=view)
build script.


-- 


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

[Bug other/43336] GCC leaves a temporary LTO output file in $TMPDIR

[d dot g dot gorbachev at gmail dot com]

--- Comment #1 from d dot g dot gorbachev at gmail dot com  2010-03-11 
19:29 ---
Created an attachment (id=20088)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20088&action=view)
Patch

This "mustard plaster" helps me.


-- 


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

[Bug bootstrap/43328] multilib bootstrap broken.

[pluto at agmk dot net]

--- Comment #9 from pluto at agmk dot net  2010-03-11 19:28 ---
Created an attachment (id=20087)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20087&action=view)
build log for very very clean source tree.


-- 


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

[Bug other/43336] New: GCC leaves a temporary LTO output file in $TMPDIR

[d dot g dot gorbachev at gmail dot com]

$ gcc -flto -fuse-linker-plugin something.c
$ ls /tmp
ccMec0Js.lto.o


-- 
   Summary: GCC leaves a temporary LTO output file in $TMPDIR
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot g dot gorbachev at gmail dot com


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

[Bug driver/43335] Driver crashes dereferencing a null pointer if it can't find lto-wrapper

[d dot g dot gorbachev at gmail dot com]

--- Comment #1 from d dot g dot gorbachev at gmail dot com  2010-03-11 
19:26 ---
Created an attachment (id=20086)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20086&action=view)
Patch

I use this patch.


-- 


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

[Bug driver/43335] New: Driver crashes dereferencing a null pointer if it can't find lto-wrapper

[d dot g dot gorbachev at gmail dot com]

To reproduce the bug,

[ rename temporarily the lto-wrapper program ]
$ gcc -fuse-linker-plugin something.c
Segmentation fault


-- 
   Summary: Driver crashes dereferencing a null pointer if it can't
find lto-wrapper
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot g dot gorbachev at gmail dot com


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

[Bug bootstrap/43328] multilib bootstrap broken.

[rwild at gcc dot gnu dot org]

--- Comment #8 from rwild at gcc dot gnu dot org  2010-03-11 18:33 ---
(In reply to comment #5)
> (In reply to comment #4)
> > Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew?
> 
> no, what for? svn status reports no unversioned files in trunk directory.

Please allow me to be dense, and ask you to *please* rm -rf the source tree and
check it out anew.  Just do it.  And then, when your build still fails, report
the revision you're building, the exact configure command line you've used, and
the error that you get, starting from the *first* error message, not the last
one.  Thanks.

A simple extra existing directory in the source tree may be the reason for the
failure, but I'm not going to search the PR database for which one it was, now,
and I don't remember off-hand.


-- 


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

[Bug bootstrap/43328] multilib bootstrap broken.

[pluto at agmk dot net]

--- Comment #7 from pluto at agmk dot net  2010-03-11 18:21 ---
(In reply to comment #6)
> > no, what for? svn status reports no unversioned files in trunk  
> > directory.
> 
> Svn status does not report .o files normally.

my ~/.subversion/config has custom global-ignores and i know what it ignores.

[~/src/gcc/trunk]$ touch x.o
[~/src/gcc/trunk]$ svn st   
?   x.o

the trunk directory is a clean checkout and bootsrap inside /tmp/BUILDDIR
fails.


-- 


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

[Bug bootstrap/43328] multilib bootstrap broken.

[pinskia at gmail dot com]

--- Comment #6 from pinskia at gmail dot com  2010-03-11 18:15 ---
Subject: Re:  multilib bootstrap broken.



Sent from my iPhone

On Mar 11, 2010, at 10:11 AM, "pluto at agmk dot net"  wrote:

>
>
> --- Comment #5 from pluto at agmk dot net  2010-03-11 18:11  
> ---
> (In reply to comment #4)
>> Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew?
>
> no, what for? svn status reports no unversioned files in trunk  
> directory.

Svn status does not report .o files normally.


>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43328
>


-- 


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

Re: [Bug bootstrap/43328] multilib bootstrap broken.

[Andrew Pinski]

Sent from my iPhone

On Mar 11, 2010, at 10:11 AM, "pluto at agmk dot net" > wrote:





--- Comment #5 from pluto at agmk dot net  2010-03-11 18:11  
---

(In reply to comment #4)

Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew?


no, what for? svn status reports no unversioned files in trunk  
directory.


Svn status does not report .o files normally.





--


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

[Bug bootstrap/43328] multilib bootstrap broken.

[pluto at agmk dot net]

--- Comment #5 from pluto at agmk dot net  2010-03-11 18:11 ---
(In reply to comment #4)
> Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew?

no, what for? svn status reports no unversioned files in trunk directory.


-- 


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

[Bug driver/43334] Generate an XML dump of the parse tree

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2010-03-11 17:37 ---
Subject: Re:   New: Generate an XML dump of the parse tree



Sent from my iPhone

On Mar 11, 2010, at 8:26 AM, "jrevans1 at earthlink dot net"
 wrote:

> Essentially I would like a feature similair to gccxml  
> (www.gccxml.org) that is
> officially blessed and native to the compiler instead of some out-of- 
> date hack.
> If a feature like this were to be officially supported, it would  
> open the doors
> to many applications who might want to use the gcc to parse its  
> files for them.

Gcc now support plugins which in my mind a better way to support  
applications which want to use gcc to parse sources.


>
> It is a good idea, with minimal impact, it just requires a "forked"  
> gcc to have
> its features.

I don't think it will be that minimal as people will depend on the  
format being constant between versions which I doubt will happen.


>
>
> -- 
>   Summary: Generate an XML dump of the parse tree
>   Product: gcc
>   Version: 4.3.0
>Status: UNCONFIRMED
>  Severity: enhancement
>  Priority: P3
> Component: driver
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: jrevans1 at earthlink dot net
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43334
>


-- 


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

Re: [Bug driver/43334] New: Generate an XML dump of the parse tree

[Andrew Pinski]

Sent from my iPhone

On Mar 11, 2010, at 8:26 AM, "jrevans1 at earthlink dot net" > wrote:


Essentially I would like a feature similair to gccxml  
(www.gccxml.org) that is
officially blessed and native to the compiler instead of some out-of- 
date hack.
If a feature like this were to be officially supported, it would  
open the doors
to many applications who might want to use the gcc to parse its  
files for them.


Gcc now support plugins which in my mind a better way to support  
applications which want to use gcc to parse sources.





It is a good idea, with minimal impact, it just requires a "forked"  
gcc to have

its features.


I don't think it will be that minimal as people will depend on the  
format being constant between versions which I doubt will happen.






--
  Summary: Generate an XML dump of the parse tree
  Product: gcc
  Version: 4.3.0
   Status: UNCONFIRMED
 Severity: enhancement
 Priority: P3
Component: driver
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: jrevans1 at earthlink dot net


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

[Bug c++/43333] [4.5 Regression] __is_pod seems broken

[redi at gcc dot gnu dot org]

--- Comment #4 from redi at gcc dot gnu dot org  2010-03-11 17:12 ---
it's both trivial and standard layout, so is a POD


-- 


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

[Bug c++/43333] [4.5 Regression] __is_pod seems broken

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2010-03-11 17:01 ---
Subject: Re:   New: __is_pod seems broken



Sent from my iPhone

On Mar 11, 2010, at 8:03 AM, "matz at gcc dot gnu dot org"
 wrote:

> On r157245 (and former revisions) this testcase will abort:
> # cat ispod.cc
> struct strPOD
> {
>  const char *const foo;
>  const char *const bar;
> };

I don't think this is a pod as it requires a non trivial constructor.



> extern "C" void abort (void);
> int main ()
> {
>  if (!__is_pod (strPOD))
>abort ();
>  return 0;
> }
>
> This manifests itself in blocxx not compiling with gcc 4.5 (due to  
> its use
> of tr1::is_pod<> implemented in terms of above).  It still works  
> with a random
> gcc 4.3 version.
>
>
> -- 
>   Summary: __is_pod seems broken
>   Product: gcc
>   Version: 4.5.0
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: c++
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: matz at gcc dot gnu dot org
>  GCC host triplet: x86_64-linux
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
>


-- 


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

Re: [Bug c++/43333] New: __is_pod seems broken

[Andrew Pinski]

Sent from my iPhone

On Mar 11, 2010, at 8:03 AM, "matz at gcc dot gnu dot org" > wrote:



On r157245 (and former revisions) this testcase will abort:
# cat ispod.cc
struct strPOD
{
 const char *const foo;
 const char *const bar;
};


I don't think this is a pod as it requires a non trivial constructor.




extern "C" void abort (void);
int main ()
{
 if (!__is_pod (strPOD))
   abort ();
 return 0;
}

This manifests itself in blocxx not compiling with gcc 4.5 (due to  
its use
of tr1::is_pod<> implemented in terms of above).  It still works  
with a random

gcc 4.3 version.


--
  Summary: __is_pod seems broken
  Product: gcc
  Version: 4.5.0
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: c++
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: matz at gcc dot gnu dot org
 GCC host triplet: x86_64-linux


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

[Bug middle-end/20491] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042

[ghazi at gcc dot gnu dot org]

--- Comment #36 from ghazi at gcc dot gnu dot org  2010-03-11 17:00 ---
I'm seeing failures for gcc.dg/torture/asm-subreg-1.c on
armv5tel-unknown-linux-gnueabi on mainline and 4.4/4.3 branches when using
-fpic or -fPIC and optimizing.  See:

http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg00638.html

The error message is:

 > asm-subreg-1.c: In function 'evas_common_convert_yuv_420p_601_rgba':
 > asm-subreg-1.c:13:3: error: 'asm' operand requires impossible reload
 > compiler exited with status 1


Is this a bug or skip it like hppa?


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot org
   Last reconfirmed|2005-03-24 08:56:02 |2010-03-11 17:00:00
   date||


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

[Bug c++/43333] [4.5 Regression] __is_pod seems broken

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-03-11 16:41 
---
I would be willing to work on this, of course, but I can't really do it now
because I'm traveling and I don't have with me all the tools I need.

Anyway, we do already have a testcase involving a pair of doubles, and I'm
surprised that now is broken for a pair of pointers, or the issue it really
about the const qualification? In any case, it doesn't look to me as possibly a
problem having to do with the implementation of the trait proper, because it
boils down to just:

case CPTK_IS_POD:
  return (pod_type_p (type1));

Maybe Jason can help a bit, I think pod_type_p has been recently changed to
deal with std_layout types, etc.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug driver/43334] New: Generate an XML dump of the parse tree

[jrevans1 at earthlink dot net]

Essentially I would like a feature similair to gccxml (www.gccxml.org) that is
officially blessed and native to the compiler instead of some out-of-date hack. 
If a feature like this were to be officially supported, it would open the doors
to many applications who might want to use the gcc to parse its files for them.

It is a good idea, with minimal impact, it just requires a "forked" gcc to have
its features.


-- 
   Summary: Generate an XML dump of the parse tree
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jrevans1 at earthlink dot net


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

[Bug c++/43333] [4.5 Regression] __is_pod seems broken

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-03-11 16:24 ---
Confirmed.  4.4 works as well.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
  Known to work||4.4.3
   Priority|P3  |P1
   Last reconfirmed|-00-00 00:00:00 |2010-03-11 16:24:31
   date||
Summary|__is_pod seems broken   |[4.5 Regression] __is_pod
   ||seems broken
   Target Milestone|--- |4.5.0


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

[Bug debug/42959] g++ does not emit DW_AT_default_value

[dodji at gcc dot gnu dot org]

--- Comment #1 from dodji at gcc dot gnu dot org  2010-03-11 16:17 ---
Created an attachment (id=20085)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20085&action=view)
Draft patch

Please find below a copy/paste of the introductory comment of the attached
patch.

Basically the value of DW_AT_default_value -- as explained by the DWARF4
draft specification -- is either a constant if the default argument of
the function is a constant, or a reference to a DIE if the value of the
default argument is a language construct like a variable.

I believe there are cases however where it's hard (impossible yet?) to
represent the value of DW_AT_default_value. For instance, when the
default argument of a function F is an arbitrary expression that
yields temporaries.  In that case, the default argument expression
must be evaluated in the context of the caller of F. Just taking in
account the default argument expression in the context of the F
declaration is not enough.
I am not sure we can represent that in DWARF today, can we?

So this patch is limited to the simple cases were the default argument
is either a constant or a variable that does not involve any temporary.
When a default argument expression involves some temporaries, no debug
info is generated for it.

For a class, it appears that we were calling finish_struct right before
parsing default arguments of the member functions.
finish_struct does the layout of the class. So we do the layout of the
class before parsing the defaut arguments because they can refer to
parts of the struct that need to be constructed before. The problem is
finish_struct also generates debug info for the class. That means, when
we generate debug info for the struct, we don't have any information
ready about the default arguments.

The patch allows finish_struct to not emit debug info systematically. We
can then keep calling finish_struct "early" and emit debug info only after
we parsed the default arguments.
We do something similar at class template instantiation time. We emit debug
info only after the template arguments are substituted into the default
arguments expressions.


-- 


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

[Bug debug/43329] Early inlining causes suboptimal debug info

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-03-11 16:08 ---
Created an attachment (id=20084)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20084&action=view)
gcc45-pr43329.patch

Updated patch that also fixes remove_forwarder_block and adds a testcase.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #20081|0   |1
is obsolete||
 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug fortran/43228] NAMELIST I/O: Reading at 2 dimensions (rank) array values.

[burnus at gcc dot gnu dot org]

--- Comment #16 from burnus at gcc dot gnu dot org  2010-03-11 16:06 ---
Subject: Bug 43228

Author: burnus
Date: Thu Mar 11 16:06:37 2010
New Revision: 157389

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157389
Log:
2010-03-11  Tobias Burnus  

PR fortran/43228
* io/list_read.c (nml_parse_qualifier): Disable expanded_read
for array sections.

2010-03-11  Tobias Burnus  

PR fortran/43228
* gfortran.dg/namelist_61.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/namelist_61.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c


-- 


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

[Bug bootstrap/43328] multilib bootstrap broken.

[rwild at gcc dot gnu dot org]

--- Comment #4 from rwild at gcc dot gnu dot org  2010-03-11 16:06 ---
Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew?


-- 


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

[Bug c++/43333] New: __is_pod seems broken

[matz at gcc dot gnu dot org]

On r157245 (and former revisions) this testcase will abort:
# cat ispod.cc
struct strPOD
{
  const char *const foo;
  const char *const bar;
};
extern "C" void abort (void);
int main ()
{
  if (!__is_pod (strPOD))
abort ();
  return 0;
}

This manifests itself in blocxx not compiling with gcc 4.5 (due to its use
of tr1::is_pod<> implemented in terms of above).  It still works with a random
gcc 4.3 version.


-- 
   Summary: __is_pod seems broken
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
  GCC host triplet: x86_64-linux


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

[Bug bootstrap/43328] multilib bootstrap broken.

[pluto at agmk dot net]

--- Comment #3 from pluto at agmk dot net  2010-03-11 16:02 ---
(In reply to comment #2)
> Quoting install.texi:
> 
> First, we @strong{highly} recommend that GCC be built into a
> separate directory from the sources which does @strong{not} reside
> within the source tree.  This is how we generally build GCC; building
> where @var{srcdir} == @var{objdir} should still work, but doesn't
> get extensive testing; building where @var{objdir} is a subdirectory
> of @var{srcdir} is unsupported.
> 
> Your build violates the latter.  Please start anew with a freshly(!) unpacked
> source tree.

ehhh, you're walking around the real bug :)

fresh build inside /tmp/BUILDDIR (sources at ~/src/gcc/trunk) ends with
the same error:

(...)
make[5]: Entering directory `/tmp/BUILDDIR/32/zlib'
make[5]: *** No rule to make target `all'.  Stop.
make[5]: Leaving directory `/tmp/BUILDDIR/32/zlib'
make[4]: *** [multi-do] Error 1
make[4]: Leaving directory `/tmp/BUILDDIR/zlib'
make[3]: *** [all-multi] Error 2
make[3]: Leaving directory `/tmp/BUILDDIR/zlib'
make[2]: *** [all-stage2-zlib] Error 2
make[2]: Leaving directory `/tmp/BUILDDIR'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/tmp/BUILDDIR'
make: *** [all] Error 2


/tmp/BUILDDIR/32/zlib/config.log:
  /home/users/pluto/src/gcc/trunk/zlib/configure:
/tmp/BUILDDIR/32/./prev-gcc/xgcc: not found


-- 

pluto at agmk dot net changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug fortran/43331] Cray pointers generate bogus IL for the middle-end

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2010-03-11 15:58 ---
Created an attachment (id=20083)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20083&action=view)
Lightly tested patch


-- 


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

[Bug bootstrap/43328] multilib bootstrap broken.

[rwild at gcc dot gnu dot org]

--- Comment #2 from rwild at gcc dot gnu dot org  2010-03-11 15:46 ---
Quoting install.texi:

First, we @strong{highly} recommend that GCC be built into a
separate directory from the sources which does @strong{not} reside
within the source tree.  This is how we generally build GCC; building
where @var{srcdir} == @var{objdir} should still work, but doesn't
get extensive testing; building where @var{objdir} is a subdirectory
of @var{srcdir} is unsupported.

Your build violates the latter.  Please start anew with a freshly(!) unpacked
source tree.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/43255] [4.5 Regression] ICE in extract_range_from_assert, at tree-vrp.c:1423

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-03-11 15:21 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/43323] [4.4 Regression] Wrong code with bitfields and type casting.

[mikpe at it dot uu dot se]

--- Comment #3 from mikpe at it dot uu dot se  2010-03-11 15:19 ---
Created an attachment (id=20082)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20082&action=view)
backport of Adam Nemet's STRIP_NOPS patch to gcc-4.4.3

I've backported Adam Nemet's STRIP_NOPS patch in r148631 to gcc-4.4.3 and added
the second PR43323 test case. Bootstrapped and regtested on i686-linux w/o
regressions. Both Adam's original test case and the PR43323 one pass with this
patch but fail without it.

I'll do more testing on other archs (arm, sparc64, powerpc64, amd64) next.


-- 


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

[Bug rtl-optimization/43332] New: valgrind warns about using uninitialized variable with -fsched-pressure -fschedule-insns

[zsojka at seznam dot cz]

This can be related to pr42941

Command line:
gcc -fschedule-insns -fsched-pressure testcase.c

 testcase.c 
extern void exit(int);
int main(int argc, char *argv[])
{
exit(0);
}



gcc has to be compiled with valgrind checking to show this warning:

$ valgrind -q --track-origins=yes
/mnt/sdb1/build-157335-lto-checking-valgrind/gcc/cc1 -fschedule-insns
-fsched-pressure testcase.c -quiet
==26448== Conditional jump or move depends on uninitialised value(s)
==26448==at 0xACFEE7: setup_insn_max_reg_pressure (haifa-sched.c:1589)
==26448==by 0x6CFA41: schedule_insns (sched-rgn.c:2965)
==26448==by 0x6CFC2D: rest_of_handle_sched (sched-rgn.c:3512)
==26448==by 0x679D8D: execute_one_pass (passes.c:1567)
==26448==by 0x679FF4: execute_pass_list (passes.c:1622)
==26448==by 0x67A006: execute_pass_list (passes.c:1623)
==26448==by 0x749E2F: tree_rest_of_compilation (tree-optimize.c:413)
==26448==by 0x876780: cgraph_expand_function (cgraphunit.c:1545)
==26448==by 0x87717F: cgraph_output_in_order (cgraphunit.c:1721)
==26448==by 0x8789D5: cgraph_optimize (cgraphunit.c:1869)
==26448==by 0x878BD4: cgraph_finalize_compilation_unit (cgraphunit.c:1093)
==26448==by 0x4A78CA: c_write_global_declarations (c-decl.c:9510)
==26448==  Uninitialised value was created by a client request
==26448==at 0x4FC1AF: ggc_alloc_stat (ggc-page.c:1228)
==26448==by 0x6C06E0: rtx_alloc_stat (rtl.c:199)
==26448==by 0x597FDA: emit_barrier_after (emit-rtl.c:4481)
==26448==by 0x525B7A: expand_call (calls.c:2911)
==26448==by 0x50F2ED: expand_builtin (builtins.c:6403)
==26448==by 0x5AFF20: expand_expr_real_1 (expr.c:9247)
==26448==by 0x52E2EB: expand_gimple_stmt (cfgexpand.c:1783)
==26448==by 0x52F0D7: expand_gimple_basic_block (cfgexpand.c:3377)
==26448==by 0x532847: gimple_expand_cfg (cfgexpand.c:3826)
==26448==by 0x679D8D: execute_one_pass (passes.c:1567)
==26448==by 0x679FF4: execute_pass_list (passes.c:1622)
==26448==by 0x749E2F: tree_rest_of_compilation (tree-optimize.c:413)
==26448== 
==26448== Conditional jump or move depends on uninitialised value(s)
==26448==at 0xACFEE7: setup_insn_max_reg_pressure (haifa-sched.c:1589)
==26448==by 0xAD4E42: schedule_insn (haifa-sched.c:1632)
==26448==by 0xAD7598: schedule_block (haifa-sched.c:3143)
==26448==by 0x6CFAA9: schedule_insns (sched-rgn.c:3001)
==26448==by 0x6CFC2D: rest_of_handle_sched (sched-rgn.c:3512)
==26448==by 0x679D8D: execute_one_pass (passes.c:1567)
==26448==by 0x679FF4: execute_pass_list (passes.c:1622)
==26448==by 0x67A006: execute_pass_list (passes.c:1623)
==26448==by 0x749E2F: tree_rest_of_compilation (tree-optimize.c:413)
==26448==by 0x876780: cgraph_expand_function (cgraphunit.c:1545)
==26448==by 0x87717F: cgraph_output_in_order (cgraphunit.c:1721)
==26448==by 0x8789D5: cgraph_optimize (cgraphunit.c:1869)
==26448==  Uninitialised value was created by a client request
==26448==at 0x4FC1AF: ggc_alloc_stat (ggc-page.c:1228)
==26448==by 0x6C06E0: rtx_alloc_stat (rtl.c:199)
==26448==by 0x597FDA: emit_barrier_after (emit-rtl.c:4481)
==26448==by 0x525B7A: expand_call (calls.c:2911)
==26448==by 0x50F2ED: expand_builtin (builtins.c:6403)
==26448==by 0x5AFF20: expand_expr_real_1 (expr.c:9247)
==26448==by 0x52E2EB: expand_gimple_stmt (cfgexpand.c:1783)
==26448==by 0x52F0D7: expand_gimple_basic_block (cfgexpand.c:3377)
==26448==by 0x532847: gimple_expand_cfg (cfgexpand.c:3826)
==26448==by 0x679D8D: execute_one_pass (passes.c:1567)
==26448==by 0x679FF4: execute_pass_list (passes.c:1622)
==26448==by 0x749E2F: tree_rest_of_compilation (tree-optimize.c:413)
==26448==


-- 
   Summary: valgrind warns about using uninitialized variable with -
fsched-pressure -fschedule-insns
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-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=43332

[Bug fortran/43331] Cray pointers generate bogus IL for the middle-end

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2010-03-11 15:10 ---
What is done for assumed-size arrays such as a(*)?


-- 


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

[Bug middle-end/43255] [4.5 Regression] ICE in extract_range_from_assert, at tree-vrp.c:1423

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-03-11 15:08 ---
Subject: Bug 43255

Author: rguenth
Date: Thu Mar 11 15:08:24 2010
New Revision: 157388

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157388
Log:
2010-03-11  Richard Guenther  

PR tree-optimization/43255
* tree-vrp.c (process_assert_insertions_for): Do not insert
asserts for trivial conditions.

* gcc.c-torture/compile/pr43255.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr43255.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c


-- 


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

[Bug fortran/43331] Cray pointers generate bogus IL for the middle-end

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-03-11 14:50 ---
I think the "1" comes about due to the following. That can either leave that
part as is and change it back in in trans*.c via "cp_was_assumed" -- or one
removes that part and sees what will break ;-)

>From decl.c:

/* Cray Pointees can be declared as:
  pointer (ipt, a (n,m,...,*))
   By default, this is treated as an AS_ASSUMED_SIZE array.  We'll
   cheat and set a constant bound of 1 for the last dimension, if this
   is the case. Since there is no bounds-checking for Cray Pointees,
   this will be okay.  */

match
gfc_mod_pointee_as (gfc_array_spec *as)
{
  as->cray_pointee = true; /* This will be useful to know later.  */
  if (as->type == AS_ASSUMED_SIZE)
{
  as->type = AS_EXPLICIT;
  as->upper[as->rank - 1] = gfc_int_expr (1);
  as->cp_was_assumed = true;
}


-- 


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

[Bug debug/43329] Early inlining causes suboptimal debug info

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-03-11 14:46 ---
Created an attachment (id=20081)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20081&action=view)
gcc45-pr43329.patch

This patch worked on this testcase.  Note that the missing min (and this) DEBUG
stmts are caused by remove_forwarder_block nuking it.  Looking into that...


-- 


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

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[jvdelisle at gcc dot gnu dot org]

--- Comment #16 from jvdelisle at gcc dot gnu dot org  2010-03-11 14:35 
---
Closing.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/43228] NAMELIST I/O: Reading at 2 dimensions (rank) array values.

[jvdelisle at gcc dot gnu dot org]

--- Comment #15 from jvdelisle at gcc dot gnu dot org  2010-03-11 14:25 
---
yes, you have to be careful as you increment through the indexes to not
overwrite a previous good initialization of end.  I suspect there is at least
one other bug in there while you are at it.  :)


-- 


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

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[hjl dot tools at gmail dot com]

--- Comment #15 from hjl dot tools at gmail dot com  2010-03-11 14:24 
---
You can find my SPEC CPU pass/fail results at

http://gcc.gnu.org/ml/gcc-testresults/

The last one is

http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg00855.html


-- 


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

[Bug target/36399] ABI bug on darwin/x86-32

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2010-03-11 14:24 
---
(In reply to comment #9)
> Should we apply the patch from comment 7 before gcc 4.5 branches?

Well, you certainly need to follow patch submission rules.  Thus, post
to gcc-patches w/ a changelog entry and stating how you tested the patch.


-- 


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

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[jvdelisle at gcc dot gnu dot org]

--- Comment #14 from jvdelisle at gcc dot gnu dot org  2010-03-11 14:20 
---
If someone confirms SPEC is cleared, please close.


-- 


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

[Bug target/36399] ABI bug on darwin/x86-32

[howarth at nitro dot med dot uc dot edu]

--- Comment #9 from howarth at nitro dot med dot uc dot edu  2010-03-11 
14:13 ---
Should we apply the patch from comment 7 before gcc 4.5 branches?


-- 


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

[Bug tree-optimization/43280] [4.5 Regression] gcc4.5 -m32 -O2: misoptimizes sha256!

[krebbel at gcc dot gnu dot org]

--- Comment #8 from krebbel at gcc dot gnu dot org  2010-03-11 14:06 ---
(In reply to comment #6)
> Why does the new testcase have
> 
> +/* { dg-require-effective-target lp64 } */
> 
> when the failure is shown with -m32 on x86-64?
> 

I've removed that in the new version. Thanks!


-- 

krebbel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/42339] [graphite] Autopar on SPEC 2006 fails

[spop at gcc dot gnu dot org]

--- Comment #1 from spop at gcc dot gnu dot org  2010-03-11 13:56 ---
Fixed as shown by the automatic tester results today:
http://groups.google.com/group/gcc-graphite-test/browse_thread/thread/cd55ed193db3862a#


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/43280] [4.5 Regression] gcc4.5 -m32 -O2: misoptimizes sha256!

[krebbel at gcc dot gnu dot org]

--- Comment #7 from krebbel at gcc dot gnu dot org  2010-03-11 13:51 ---
Subject: Bug 43280

Author: krebbel
Date: Thu Mar 11 13:51:00 2010
New Revision: 157386

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157386
Log:
2010-03-11  Andreas Krebbel  

PR tree-optimization/43280
* tree-ssa-math-opts.c (find_bswap_1): Modify symbolic number
generation.
Move calculation of size out of the if branch.
(find_bswap): Modify compare number generation.

2010-03-11  Andreas Krebbel  

* gcc.dg/optimize-bswapdi-1.c: Add OpenSSL bswap variant.
* gcc.dg/pr43280.c: New testcase.



Added:
trunk/gcc/testsuite/gcc.dg/pr43280.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/optimize-bswapdi-1.c
trunk/gcc/tree-ssa-math-opts.c


-- 


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

[Bug lto/43200] [LTO] tree check: expected array_type, have pointer_type in array_ref_low_bound

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-03-11 13:14 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug lto/43200] [LTO] tree check: expected array_type, have pointer_type in array_ref_low_bound

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-03-11 13:14 ---
Subject: Bug 43200

Author: rguenth
Date: Thu Mar 11 13:13:53 2010
New Revision: 157385

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157385
Log:
2010-03-11  Richard Guenther  

PR lto/43200
* lto-streamer-in.c (maybe_fixup_decls): Simplify.
(input_gimple_stmt): Fixup handled component types during
operand read.  Also fix up decls in ADDR_EXPRs.

* gcc.dg/lto/20100227-1_0.c: New testcase.
* gcc.dg/lto/20100227-1_1.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/lto/20100227-1_0.c
trunk/gcc/testsuite/gcc.dg/lto/20100227-1_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-in.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/43315] Variadic Templates affects the overload resolution rank

[redi at gcc dot gnu dot org]

--- Comment #5 from redi at gcc dot gnu dot org  2010-03-11 13:12 ---
Yes, I saw your mail to the std reflector.  As I said in my reply there, I
don't understand the rules, but GCC seems to be following them correctly.
Closing this bug.


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug debug/43329] Early inlining causes suboptimal debug info

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-03-11 13:02 ---
Wonder why we do
548VEC_safe_push (tree, gc, *nonlocalized_list, origin_var);
instead of
548VEC_safe_push (tree, gc, *nonlocalized_list, old_var);
The latter perhaps would need some adjustments in dwarf2out.c, but would allow
it to find the location.


-- 


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

[Bug fortran/43228] NAMELIST I/O: Reading at 2 dimensions (rank) array values.

[burnus at gcc dot gnu dot org]

--- Comment #14 from burnus at gcc dot gnu dot org  2010-03-11 12:58 ---
Mine! I now do as written in comment #13 - except for the "if" which is not
needed (it use the wrong index and wouldn't work anyhow) - and except for
moving it down a bit.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|jvdelisle at gcc dot gnu dot|burnus at gcc dot gnu dot
   |org |org


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

[Bug debug/43329] Early inlining causes suboptimal debug info

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-03-11 12:53 ---
The problem is that with early inlining, method (&inst, 24) call is inlined
into
call function, then at the end of einline during arrg3 and min vars in call are
removed as unused locals by remove_unused_locals (the inline asm uses 24
directly, so arrg3 is only referenced in DEBUG stmts, not sure why min didn't
have any DEBUG stmts even generated).  Then when in the normal inliner call is
inlined into main, both arrg3 and min are non-localized because their var_ann
is NULL.  And for non-localized vars dwarf2out isn't able to find the
dwarf2out_var_location tracked values.


-- 


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

[Bug pending/41998] GCC 4.6 pending patches meta-bug

[manu at gcc dot gnu dot org]

--- Comment #13 from manu at gcc dot gnu dot org  2010-03-11 12:50 ---
And if the patch fixes a PR, it is better to link to the patch from the
original PR and add the PR to the list of bugs that this PR depend on (you can
use the alias "4.6" in the field "Bug X blocks" of your PR).


-- 


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

[Bug middle-end/30506] not sibcalling a function

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-03-11 12:34 ---
That's not a bug.  Unlike x86-64, on i?86 when calling (or jumping to) a PLT
slot in position independent code %ebx must be set to the calling function's
PIC pointer.  As %ebx is call saved register, this precludes sibcall.


-- 


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

[Bug c++/43315] Variadic Templates affects the overload resolution rank

[boostcpp at gmail dot com]

--- Comment #4 from boostcpp at gmail dot com  2010-03-11 12:26 ---
It looks like gcc is correct.


-- 


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

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[ubizjak at gmail dot com]

--- Comment #65 from ubizjak at gmail dot com  2010-03-11 12:18 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug c++/43324] core dump on throw

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-03-11 12:13 ---
Works on linux.


-- 


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

[Bug fortran/43331] New: Cray pointers generate bogus IL for the middle-end

[rguenth at gcc dot gnu dot org]

I have a patch that exposes this and causes a "miscompile" of
gfortran.dg/cray_pointers_2.f90.  Reduced testcase:

! { dg-do run }
! { dg-options "-fcray-pointer -fbounds-check" }
! Series of routines for testing a Cray pointer implementation
program craytest
  call ptr5
end program craytest

subroutine ptr5
  logical :: intne
  integer :: i
  integer, parameter :: n = 9
  integer itarg1 (n)
  integer ipte1 (*)

  pointer(iptr4,ipte1)

  iptr4 = loc(itarg1)

  do, i=1,n
 ipte1(i) = i
 if (intne(ipte1(i), itarg1(i))) then
! Error #143
call abort()
 endif
  end do

end subroutine ptr5

! Separate function calls to break Cray pointer-indifferent optimization
logical function intne(ii,jj)
  integer :: i,j
  intne = ii.ne.jj
  if (intne) then
 write (*,*) ii," doesn't equal ",jj
  endif
end function intne


where we can see the following IL created by the FE:

ptr5 ()
{
  integer(kind=4) i;
  integer(kind=8) iptr4;
  integer(kind=4) ipte1[1] [value-expr: *(integer(kind=4)[1] *) iptr4];
  integer(kind=4) itarg1[9];

  {
integer(kind=8) D.1548;

D.1548 = (integer(kind=8)) &itarg1;
iptr4 = D.1548;
  }
...
ipte1[NON_LVALUE_EXPR > + -1] = i;
...
if (intne (&ipte1[NON_LVALUE_EXPR >
+ -1], &itarg1[NON_LVALUE_EXPR > + -1]))


you can clearly see that substituting the value-expr
*(integer(kind=4)[1] *) iptr4 for ipte1 will expose an array size of 1 (!)
to the middle-end, which it will happily oblige to and optimize
&ipte1[i - 1] to &ipte1[0].

If the array size is not known the FE should generate
*(integer(kind=4)[] *) iptr4


-- 
   Summary: Cray pointers generate bogus IL for the middle-end
   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: rguenth at gcc dot gnu dot org


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

[Bug c++/43330] trivial types are not being statically initialized

[eric dot niebler at gmail dot com]

--- Comment #3 from eric dot niebler at gmail dot com  2010-03-11 11:56 
---
Oops, it's not an aggregate. Disregard.


-- 

eric dot niebler at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/43330] trivial types are not being statically initialized

[eric dot niebler at gmail dot com]

--- Comment #2 from eric dot niebler at gmail dot com  2010-03-11 11:53 
---
You're right. Let me amend my example.

  struct S
  {
S() = default;
S(S const &) = default;
S(int i) : i(i) {}
int i;
  };

  S const s {1};

S would seem to satisfy the requirements for a trivial type now, correct? N2342
states:

"When an aggregate with static storage duration is initialized with a
brace-enclosed initializer-list, if all the member initializer expressions are
constant expressions, and the aggregate is a trivial type, the initialization
shall be done during the static phase of initialization"

GCC initializes s dynamically. That doesn't seem right. I see that constant
expressions are not yet implemented in gcc-4.5. Am I correct in assuming that
once constant expressions are implemented, this initialization will be static?


-- 


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

[Bug c++/43330] trivial types are not being statically initialized

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2010-03-11 11:41 ---
Subject: Re:   New: trivial types are not being statically initialized



Sent from my iPhone

On Mar 11, 2010, at 3:24 AM, "eric dot niebler at gmail dot com"
 wrote:

> According to the C++0x status page
> (http://gcc.gnu.org/gcc-4.5/cxx0x_status.html), "Standard Layout  
> Types"
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm)  
> have been
> implemented in gcc-4.5. A quick test shows that trivial types are  
> not being
> statically initialized, as the paper requires. The following struct  
> S is
> trivial and the non-local constant s should be statically  
> initialized, IIUC:
>
>  struct S
>  {
>S() {}
>  };

The above is not a trivial type though. It has a non trivial default  
constructor. If you want a trivial constructor use either "= default"  
or delete it all together.


>
>  S const s{};
>
> However, when compiled with -O2 -std=c++0x -S using the latest 4.5  
> snapshot, I
> see the following assembly:
>
>.file   "main.cpp"
>.text
>.p2align 4,,15
>.def__GLOBAL__I_main.cpp;   .scl3;  .type
> 32; .endef
> __GLOBAL__I_main.cpp:
>pushl   %ebp
>movl%esp, %ebp
>popl%ebp
>ret
>.section.ctors,"w"
>.align 4
>.long   __GLOBAL__I_main.cpp
>
> Unless I'm mistaken, the global s is still being dynamically  
> initialized.
> Apologies in advance if I'm reading this wrong.
>
>
> -- 
>   Summary: trivial types are not being statically initialized
>   Product: gcc
>   Version: 4.5.0
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: c++
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: eric dot niebler at gmail dot com
> GCC build triplet: gcc-4.5-20100304
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43330
>


-- 


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

Re: [Bug c++/43330] New: trivial types are not being statically initialized

[Andrew Pinski]

Sent from my iPhone

On Mar 11, 2010, at 3:24 AM, "eric dot niebler at gmail dot com" > wrote:



According to the C++0x status page
(http://gcc.gnu.org/gcc-4.5/cxx0x_status.html), "Standard Layout  
Types"
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm)  
have been
implemented in gcc-4.5. A quick test shows that trivial types are  
not being
statically initialized, as the paper requires. The following struct  
S is
trivial and the non-local constant s should be statically  
initialized, IIUC:


 struct S
 {
   S() {}
 };


The above is not a trivial type though. It has a non trivial default  
constructor. If you want a trivial constructor use either "= default"  
or delete it all together.





 S const s{};

However, when compiled with -O2 -std=c++0x -S using the latest 4.5  
snapshot, I

see the following assembly:

   .file   "main.cpp"
   .text
   .p2align 4,,15
   .def__GLOBAL__I_main.cpp;   .scl3;  .type
32; .endef

__GLOBAL__I_main.cpp:
   pushl   %ebp
   movl%esp, %ebp
   popl%ebp
   ret
   .section.ctors,"w"
   .align 4
   .long   __GLOBAL__I_main.cpp

Unless I'm mistaken, the global s is still being dynamically  
initialized.

Apologies in advance if I'm reading this wrong.


--
  Summary: trivial types are not being statically initialized
  Product: gcc
  Version: 4.5.0
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: c++
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: eric dot niebler at gmail dot com
GCC build triplet: gcc-4.5-20100304


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

[Bug c++/43330] New: trivial types are not being statically initialized

[eric dot niebler at gmail dot com]

According to the C++0x status page
(http://gcc.gnu.org/gcc-4.5/cxx0x_status.html), "Standard Layout Types"
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm) have been
implemented in gcc-4.5. A quick test shows that trivial types are not being
statically initialized, as the paper requires. The following struct S is
trivial and the non-local constant s should be statically initialized, IIUC:

  struct S
  {
S() {}
  };

  S const s{};

However, when compiled with -O2 -std=c++0x -S using the latest 4.5 snapshot, I
see the following assembly:

.file   "main.cpp"
.text
.p2align 4,,15
.def__GLOBAL__I_main.cpp;   .scl3;  .type   32; .endef
__GLOBAL__I_main.cpp:
pushl   %ebp
movl%esp, %ebp
popl%ebp
ret
.section.ctors,"w"
.align 4
.long   __GLOBAL__I_main.cpp

Unless I'm mistaken, the global s is still being dynamically initialized.
Apologies in advance if I'm reading this wrong.


-- 
   Summary: trivial types are not being statically initialized
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com
 GCC build triplet: gcc-4.5-20100304


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

[Bug middle-end/40815] redundant neg instruction caused by loop-invariant

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-03-11 11:19 ---
+   ops_arr[op_num] = build1 (NOP_EXPR,
+ TREE_TYPE (gimple_assign_lhs
+(neg)),
+ gimple_assign_rhs1 (neg));

you shouldn't need the conversion.

Btw, as you do not handle POINTER_PLUS_EXPR to compensate the lack of
POINTER_MINUS_EXPR doing the transformation during expansion is bogus.
Instead general re-association should do it.  My original suggestion
was to amend the POINTER_PLUS_EXPR case in expand_expr_real_2 to
lookup the TER expression for treeop1 and in case of it being defined
as -X dispatch to the MINUS_EXPR expansion.


-- 


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

[Bug fortran/43303] [4.4/4.5 Regression] ICE with C_ASSOCIATED

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2010-03-11 11:12 ---
FIXED on the trunk (4.5) and the 4.4 branch. Thanks for the bug report!


-- 

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

[Bug fortran/43303] [4.4/4.5 Regression] ICE with C_ASSOCIATED

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2010-03-11 11:10 ---
Subject: Bug 43303

Author: burnus
Date: Thu Mar 11 11:10:37 2010
New Revision: 157383

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157383
Log:
2010-03-11  Tobias Burnus  result.

2010-03-11  Tobias Burnus  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43303

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[burnus at gcc dot gnu dot org]

--- Comment #13 from burnus at gcc dot gnu dot org  2010-03-11 11:08 ---
(In reply to comment #10)
> I plan to commit the following as a compromise.  We have had several PRs here
> that contradict.

I am not sure whether the PRs really contradict as they just ask "do what the
other compilers do", which is arguably not well defined but non-contradicting
so far - the standard is (on purpose) not very explicit, unfortunately.
(Fortunately, ifort, openf95, NAG f95 give the same result so far - and only
for few special cases, gfortran does not.)

> All of these involve missing EOR at the end of a file.  Some want the EOF to
> be interpreted as the EOR and some don't. As a follow-up patch I am wondering
> if we should treat the missing EOR at EOF as an EOR with -std=legacy and
> default to giving an EOF otherwise.

I am extremely unhappy about different run-time behaviour depending on some
compile-time flags as it causes differences, which are extremely difficult to
pin point - both for the users and for us during bug reports.

The common notion seems to be: If there is any character read before ,
that's a normal record and reading e.g. "(a80)" or "(100x)" or "(i20)"  is
allowed. If there is no character, not even a "\n", reading anything implies
EOF.

 * * *

Can this PR now be closed?


-- 


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

[Bug middle-end/30506] not sibcalling a function

[pluto at agmk dot net]

--- Comment #5 from pluto at agmk dot net  2010-03-11 09:40 ---
recent 4.5.0 sibcalls this on x86-64 only:

/opt/gcc45/bin/g++45 t.cpp -O2 -S -m64 -fpie -o t64.s

_Z1gc:
.cfi_startproc
subq$131080, %rsp
.cfi_def_cfa_offset 131088
movl$131072, %edx
xorl%esi, %esi
movq%rsp, %rdi
callmem...@plt
xorl%edi, %edi
addq$131080, %rsp
.cfi_def_cfa_offset 8
jmp _z...@plt

/opt/gcc45/bin/g++45 t.cpp -O2 -S -m32 -fpie -o t32.s

_Z1gc:
.cfi_startproc
pushl   %ebp
.cfi_def_cfa_offset 8
movl%esp, %ebp
.cfi_offset 5, -8
.cfi_def_cfa_register 5
pushl   %ebx
.cfi_offset 3, -12
call__i686.get_pc_thunk.bx
addl$_GLOBAL_OFFSET_TABLE_, %ebx
subl$131092, %esp
leal-131080(%ebp), %eax
movl$131072, 8(%esp)
movl$0, 4(%esp)
movl%eax, (%esp)
callmem...@plt
movl$0, (%esp)
call_z...@plt
addl$131092, %esp
popl%ebx
.cfi_restore 3
popl%ebp
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc


-- 


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

[Bug pending/41998] GCC 4.6 pending patches meta-bug

[kaushik dot phatak at kpitcummins dot com]

--- Comment #12 from kaushik dot phatak at kpitcummins dot com  2010-03-11 
09:08 ---
> Rather than attach patches here, it would be better to link to the mailing
> message where the patch was approved.

Understood. This patch has been approved,
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00165.html


-- 


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

[Bug middle-end/40815] redundant neg instruction caused by loop-invariant

[mkuvyrkov at gcc dot gnu dot org]

--- Comment #8 from mkuvyrkov at gcc dot gnu dot org  2010-03-11 08:57 
---
Created an attachment (id=20080)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20080&action=view)
Fixed and tested patch

Well, sure enough the initial patch had an error: `(-a) + (-b)' was getting
optimized into `a + b' instead of (-a) - b.  This new version was tested on
x86_64 without regressions and fixes.  Any comments before I post it to
gcc-patches@ ?

Thanks.


-- 

mkuvyrkov at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #20077|0   |1
is obsolete||


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