[Bug c++/47356] New: Internal error when assigning with incomplete uniform initializer list

[thunderliu at gmail dot com]

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

   Summary: Internal error when assigning with incomplete uniform
initializer list
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thunder...@gmail.com


Created attachment 23027
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23027
preprocessed source

gcc reports internal error when assigning an aggregate with a brace-enclosed
initializer list (should report normal compile error instead).

struct C {
C();
};

struct A {
bool i;
C p[1];
};

void foo()
{
A a1;
a1 = { false };
}

$ g++ -std=c++0x -c gcc_bug.C
gcc_bug.C: In function 'void foo()':
gcc_bug.C:13: internal compiler error: in build_value_init_noctor, at
cp/init.c:406

[Bug fortran/47240] [F03] segfault with procedure pointer component

[m.a.hulsen at tue dot nl]

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

--- Comment #17 from Martien Hulsen  2011-01-19 
08:34:21 UTC ---
(In reply to comment #16)
> Fixed with r168973.

Indeed. Thanks. All my test problems for my FEM code run correctly now with
gfortran.

[Bug libstdc++/47354] [4.3/4.4/4.5 Regression] bitmap_allocator free_list::_M_get never locks mutex

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  2011-01-19 
08:50:02 UTC ---
Author: redi
Date: Wed Jan 19 08:49:58 2011
New Revision: 168985

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168985
Log:
2011-01-19  Graham Reed  

PR libstdc++/47354
* src/bitmap_allocator.cc (free_list::_M_get): Lock mutex.


Modified:
branches/gcc-4_5-branch/libstdc++-v3/ChangeLog
branches/gcc-4_5-branch/libstdc++-v3/src/bitmap_allocator.cc

[Bug libstdc++/47354] [4.3/4.4/4.5 Regression] bitmap_allocator free_list::_M_get never locks mutex

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  2011-01-19 
08:50:33 UTC ---
Author: redi
Date: Wed Jan 19 08:50:29 2011
New Revision: 168986

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168986
Log:
2011-01-19  Graham Reed  

PR libstdc++/47354
* src/bitmap_allocator.cc (free_list::_M_get): Lock mutex.


Modified:
branches/gcc-4_4-branch/libstdc++-v3/ChangeLog
branches/gcc-4_4-branch/libstdc++-v3/src/bitmap_allocator.cc

[Bug c++/47356] Internal error when assigning with incomplete uniform initializer list

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.19 08:53:14
 CC||jason at redhat dot com
  Known to work||4.6.0
 Ever Confirmed|0   |1
  Known to fail||4.4.6, 4.5.3

--- Comment #1 from Jonathan Wakely  2011-01-19 
08:53:14 UTC ---
confirmed, 4.6 compiles the code without error.

Jason, is 4.6 correct, and if so should it be WONTFIX for 4.4 & 4.5?

[Bug libstdc++/47354] [4.3 Regression] bitmap_allocator free_list::_M_get never locks mutex

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||4.4.6, 4.5.3
Summary|[4.3/4.4/4.5 Regression]|[4.3 Regression]
   |bitmap_allocator|bitmap_allocator
   |free_list::_M_get never |free_list::_M_get never
   |locks mutex |locks mutex

--- Comment #12 from Jonathan Wakely  2011-01-19 
08:56:51 UTC ---
fixed for 4.4.6 and 4.5.3 too

[Bug c++/47357] New: volatile member function is not treated as volatile

[yottui at yahoo dot co.jp]

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

   Summary: volatile member function is not treated as volatile
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yot...@yahoo.co.jp


When I execute the following test code with '-O2 -msse2' compiler options, it
outputs the wrong value.
I'm expecting that pC[1] will be 2.

operator[](int) is defined as volatile. However v is not treated as volatile.
And I tried (volatile const u &) instead of (const u &) when the casting, but
it's not affected.

-- begin test case --
//g++ -O2 -msse2 test.cpp
#include 
#include 
#include 

#define NELEM 1

struct int4
{
__m128i v;

int4(__m128i a) : v(a) {}

int4(int a0, int a1, int a2, int a3)
: v(_mm_setr_epi32(a0, a1, a2, a3)) {}

operator __m128i() const { return v; }

int operator [](int i) volatile const
{
union u {
__m128i m128;
int i32[4];
};

return ((const u &)v).i32[i];
}
};

inline int4 operator <<(const int4 & a, const int4 & b)
{ return int4(a[0]<

[Bug gcov-profile/47358] New: Decimal number formatting not localized

[thenlich at users dot sourceforge.net]

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

   Summary: Decimal number formatting not localized
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


Percentage values are displayed with a dot as decimal separator instead of the
comma which would be correct for the German locale.

Example:

$ gcov -v
gcov (GCC) 4.3.4 20090804 (release) 1
Copyright (C) 2008 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.

$ gcov testcov.c
File: »testcov.c«
50.00% von 6 Zeilen ausgeführt
testcov.c: »testcov.c.gcov« wird erzeugt

Expected output:
...
50,00% von 6 Zeilen ausgeführt
...

[Bug c++/47291] [4.6 Regression] ICE: SIGSEGV in size_binop_loc (fold-const.c:1427) with -g

[dodji at gcc dot gnu.org]

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

--- Comment #3 from Dodji Seketeli  2011-01-19 
09:49:06 UTC ---
Patch submitted to http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01282.html

[Bug target/36861] [4.5/4.6 Regression] boost's compressed avl confuses GCC

[rguenther at suse dot de]

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

--- Comment #39 from rguenther at suse dot de  
2011-01-19 09:54:19 UTC ---
On Tue, 18 Jan 2011, igaztanaga at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
> 
> --- Comment #38 from Ion Gaztañaga  2011-01-18 
> 19:15:22 UTC ---
> Thanks Richard for the detailed report. The fact is that the next standard is
> trying to support relative pointers for container implementations (much like
> Boost.Interprocess does), to be able to place containers in shared memory. In
> those cases the relative pointers stores the difference between "this" and the
> pointee, which is what boost::interprocess::offset_ptr does.

But then the pointer arithmetic will not cause the pointer to move
from one object to another - the object will be simply the shared memory
segment (which isn't statically allocated either) - that's perfectly
valid in C and C++ right now.

> It is certainly outside the standard right now and the standard won't include
> such "relative pointer" class, but it will require to container 
> implementations
> to support them as allocator::pointer types. It would be important to find a
> way to use smart pointers, maybe with some existing annotation/attribute to
> avoid optimizing away that relative addressing, so that there is always away 
> to
> compute the pointee address based on "this" + this->m_offset. It is also
> important to support smart pointers created on the stack pointing to global
> objects (temporaries, function arguments, etc.)
> 
> I know this is outside the bug, but it will be certainly a common question 
> when
> using GCC and next standard containers. Thanks

The point with the case in question is that a pointer to a global
object is computed relative to the address _of an automatic variable_.
I hope no standard will ever allow that ;)  It might be a simple
oversight (and thus bug) in Boost AVL though.

If the object were a global one then you wouldn't trigger the particular
bug (though still GCC would conclude that the pointer is pointing to
that global object, which, when in statically allocated storage, can
still lead to "miscompilations").

Richard.

[Bug rtl-optimization/47216] [4.6 Regression] gcc.dg/torture/pr43360.c FAILs with -O -fPIC -fgcse -fgcse-sm -fnon-call-exceptions -fno-tree-dse

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  
2011-01-19 09:55:48 UTC ---
On Tue, 18 Jan 2011, stevenb.gcc at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47216
> 
> --- Comment #7 from stevenb.gcc at gmail dot com  com> 2011-01-18 21:42:50 UTC ---
> Resolved alright -- but including tree-flow.h in emit-rtl.c??? :-(

We don't have tree-eh.h and tree-flow.h is yet another 
container-of-random-crap.   Btw, emit-rtl.c is part of expand, so it
definitely crosses the border and uses lots of tree stuff.

Richard.

[Bug target/45701] [4.6 Regression] Fail to prefer using r3 for padding a push/pop multiple to 8-byte alignment

[ramana at gcc dot gnu.org]

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

--- Comment #9 from Ramana Radhakrishnan  2011-01-19 
10:39:28 UTC ---
(In reply to comment #7)
> On IRC you've mentioned some TLS test issues, were they caused by this patch 
> or
> unrelated?

Sorry about the delay in responding. With trunk I see no new regressions with
my testing configurations . The tls failures were unrelated to this patch. 

Ok to submit 



Ramana

[Bug c++/47357] volatile member function is not treated as volatile

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2011-01-19 
10:44:54 UTC ---
I can't see anything in the program that would be affected by a 'volatile'
keyword.  Instead I see a lot of bogus ways to try to circumvent type-based
aliasing rules (using volatile is one).  Use -fno-strict-aliasing.

[Bug c/47351] Segmentation fault in MinGW

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-01-19 
10:47:25 UTC ---
Can you try a more recent release from the 4.5 branch, like 4.5.1 or 4.5.2?

[Bug c++/47338] [4.5 Regression] cc1plus returns exit code 5

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-01-19 
10:49:04 UTC ---
So you ran out of stack-space during garbage collecting.  A not uncommon
problem.  As you can reproduce it you now need to identify the chain
that is walked and see if we can avoid the recursion at some place.
Or simply assign more stack-space to cc1plus (what's the default on
mingw32 for that?)

[Bug tree-optimization/47179] [4.5/4.6 Regression] SPU: errno misoptimization around malloc call

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|4.5.3   |4.6.0

[Bug fortran/47359] New: Recursive functions of intrinsic names generates invalid assembler

[roger.ferrer at bsc dot es]

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

   Summary: Recursive functions of intrinsic names generates
invalid assembler
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: roger.fer...@bsc.es


I know this is sort of a contrived case but seems that gfortran is getting
confused in this case leading to syntactically invalid assembler.

RECURSIVE FUNCTION MAX(A, B) RESULT(K)
  IF (B >= 0) THEN
 K = MAX(A+1, B-1)
  ELSE
 K = A
  END IF
END

$ gfortran -c test.f90 -save-temps
test.s:11: Error: junk at end of line, first unrecognized character is `('
test.s:12: Error: unrecognized symbol type ""
test.s:12: Error: junk at end of line, first unrecognized character is `('
test.s:13: Error: Unrecognized opcode: `__(intrinsic)__max:'
test.s:73: Error: expected comma after name `__' in .size directive
$ cat -n test.s 
  ...
11.globl __(intrinsic)__max
12.type__(intrinsic)__max, @function
13__(intrinsic)__max:
  ...
73.size__(intrinsic)__max,.-__(intrinsic)__max


My guess is that gfortran is picking the intrinsic 'max' function symbol
instead of the one being currently defined (which is recursive and thus is
eligible to be called in its same body, isn't it?)

I don't know how much conformant this is to Fortran standard but Intel Fortran
and IBM XL Fortran did not complain and successfully generated an object file. 

If this is not valid Fortran, an error message is better than a cryptic
assembler syntax error :)

[Bug gcov-profile/38292] [4.3/4.4/4.5/4.6 Regression] corrupted profile info with -O[23] -fprofile-use

[doko at ubuntu dot com]

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

--- Comment #13 from Matthias Klose  2011-01-19 
11:43:30 UTC ---
trying to build python 3.2~rc1, I run into:

I get (with the just built python (built with -fprofile-generate):

build-static$ ./python
XXX lineno: 1101, opcode: 0
Fatal Python error: Py_Initialize: Unable to get the locale encoding
Traceback (most recent call last):
  File
"/home/packages/python/3.2/python3.2-3.2~rc1/build-static/../Lib/encodings/__init__.py",
line 31, in 
XXX lineno: 39, opcode: 0
Aborted

The build is ok with the normal build.

[Bug gcov-profile/38292] [4.3/4.4/4.5/4.6 Regression] corrupted profile info with -O[23] -fprofile-use

[doko at ubuntu dot com]

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

--- Comment #14 from Matthias Klose  2011-01-19 
11:53:54 UTC ---
no, normal python build fails too, this is reported as bug #47271.

[Bug libgcj/44415] [4.6 regression] gmp multilib support broke bootstrap with static libgmp

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-01-19 
12:01:02 UTC ---
(In reply to comment #3)
> Subject: Re:  [4.6 regression] gmp multilib support broke bootstrap with 
> static
> libgmp
> 
> > --- Comment #1 from pinskia at gcc dot gnu dot org  2010-06-04 17:48 
> > ---
> > First off this is not a regression; I ran into this issue back a couple of
> > years ago with libjava requiring libgmp.
> 
> It sure is: you used to be able to bootstrap with a static, non-PIC
> libgmp until this change went in, and now bootstrap fails.  If this is
> not a regression, what is?

How did it then succeed to link libjavamath.so?

Can one of you prepare an install manual patch to say that a PIC libgmp
is required for building libjava?

[Bug c++/46890] [4.6 Regression] Failed to compile scummvm's player_v4a.cpp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 AssignedTo|froydnj at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  2011-01-19 
12:24:31 UTC ---
Created attachment 23028
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23028
gcc46-pr46890.patch

Untested fix.

[Bug target/45701] [4.6 Regression] Fail to prefer using r3 for padding a push/pop multiple to 8-byte alignment

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

[Bug tree-optimization/47355] [4.6 Regression] ICE: verify_ssa failed with -O2 -fipa-cp-clone

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  2011-01-19 
12:48:57 UTC ---
>From what I have seen, it's pass_cleanup_eh removing an SSA
(names$_storage_94) name that is still being referenced in the IL (as
a parameter to zfree).

[Bug tree-optimization/46021] 3 tree-ssa tests XPASS almost everywhere

[uweigand at gcc dot gnu.org]

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

--- Comment #6 from Ulrich Weigand  2011-01-19 
12:56:19 UTC ---
Author: uweigand
Date: Wed Jan 19 12:56:16 2011
New Revision: 168990

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168990
Log:
PR tree-optimization/46021
* gcc.dg/tree-ssa/20040204-1.c: Do not XFAIL on spu-*-*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/20040204-1.c

[Bug c/47351] Segmentation fault in MinGW

[gcc.hall at gmail dot com]

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

--- Comment #4 from Jeremy  2011-01-19 13:06:41 UTC 
---
Done.  I can report that the problem does not occur with GCC 4.5.2

[Bug testsuite/45342] FAIL: gcc.dg/tls/thr-cse-1.c scan-assembler-not emutls_get_address.*emutls_get_address.*

[uweigand at gcc dot gnu.org]

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

--- Comment #3 from Ulrich Weigand  2011-01-19 
13:09:56 UTC ---
Author: uweigand
Date: Wed Jan 19 13:09:51 2011
New Revision: 168992

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168992
Log:
PR testsuite/45342
* gcc.dg/tls/thr-cse-1.c: Fix match on spu-*.*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tls/thr-cse-1.c

[Bug tree-optimization/47355] [4.6 Regression] ICE: verify_ssa failed with -O2 -fipa-cp-clone

[zsojka at seznam dot cz]

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

--- Comment #4 from Zdenek Sojka  2011-01-19 13:27:34 
UTC ---
Created attachment 23029
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23029
more reduced testcase

$ gcc -O -fipa-cp -fipa-cp-clone testcase.C
testcase.C: In function 'void foo()':
testcase.C:30:1: error: definition in block 15 does not dominate use in block
14
testcase.C:30:1: error: no immediate_use list
for SSA_NAME: D.2189_30 in statement:
names$_storage_26 = D.2189_30 + D.2160_19;
testcase.C:30:1: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(r168850, x86_64-linux)

[Bug other/47167] Performance regression in numerical code

[mar...@mpa-garching.mpg.de]

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

--- Comment #7 from Martin Reinecke  2011-01-19 
14:16:18 UTC ---
OK, I located the problematic commit, at least on the 4.5 branch: it's revision
number 167492 (fix for PR tree-optimization/46806).

Between revisions 167491 and 167492 the CPU time for the testcase2.c jumps from
4.7s to 5.4s.

Do you think that anything can be done about this regression?

[Bug tree-optimization/44688] [4.6 Regression] Excessive code-size growth at -O3

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.19 14:49:39
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-01-19 
14:49:39 UTC ---
Confirmed.

Leslie3d code-size almost doubled compared to 4.5 (and is even worse compared
to 4.4).

With -O3 -ffast-math -funroll-loops -fprefetch-loop-arrays
> ls -l 
> benchspec/CPU2006/437.leslie3d/run/build_base_amd64-m64-gcc42-nn./leslie3d
>  
-rwxrwxr-x 1 rguenther suse 572893 Jan 19 13:11
benchspec/CPU2006/437.leslie3d/run/build_base_amd64-m64-gcc42-nn./leslie3d

With -O3 -ffast-math -funroll-loops
> ls -l 
> benchspec/CPU2006/437.leslie3d/run/build_base_amd64-m64-gcc42-nn./leslie3d
>  
-rwxrwxr-x 1 rguenther suse 368093 Jan 19 13:14
benchspec/CPU2006/437.leslie3d/run/build_base_amd64-m64-gcc42-nn./leslie3d

so the regression is mostly prefetching enabled at -O3 for AMD archs.

prefetching + RTL loop unrolling: 638680
prefetching: 356736
: 274088

there are several issues.

1) prefetching doesn't re-use the epilogue loop created by the vectorizer
2) the RTL loop unroller unrolls both epilogue loops
3) for both epilogue loops we usually know an integer upper bound for
the number of iterations, but we are not able to compute it

also the vectorizer checks use various different variables to test
bounds agains which doesn't even allow us to simplify the effective
niter == 0 || niter <= 6 style tests ... that obviously does not
help the situation.

On the tree level we see things like

:
  vectorizer check
  if (bnd.24_140 <= 1)
goto ;  // unvectorized loop
  else
goto ;

:
  prefetcher check
  if (bnd.24_140 > 4)
goto ;
  else
goto ;

:
:
  # ivtmp.36_174 = PHI <0(9), ivtmp.36_197(10)>
  ivtmp.36_197 = ivtmp.36_174 + 4;
  if (...)
goto ;
  else
goto ;

:
  # ivtmp.36_176 = PHI <0(8), ivtmp.36_197(10)>

:
  # ivtmp.36_193 = PHI 
  ivtmp.36_192 = ivtmp.36_193 + 1;
  if (bnd.24_140 <= ivtmp.36_192)
goto ;
  else
goto ;

and we should be able to derive that the epilogue loop runs at most
3 times.  On RTL this seems to be difficult also because we changed
IVs again to pointers.

So the things to do are:

 1) preserve loop information across expand (and up to loop2_init)
 2) compute number of iteration information right before expand
 3) make IPA inlining integration be performed before tree loop optimizers
 4) preserve loop information starting with tree loop optimizers
 5) ...

In the end this regression shows at -O3 - an optimization flag setting
that is documented to eventually have this kind of effects.  P2.

[Bug rtl-optimization/47337] [4.6 Regression] Wrong RTL dce of calls

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-01-19 
15:13:05 UTC ---
Author: jakub
Date: Wed Jan 19 15:13:01 2011
New Revision: 168997

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168997
Log:
PR rtl-optimization/47337
* dce.c (check_argument_store): New function.
(find_call_stack_args): Ignore debug insns.  Use check_argument_store.

* gcc.c-torture/execute/pr47337.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr47337.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dce.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/47337] [4.6 Regression] Wrong RTL dce of calls

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2011-01-19 
15:15:36 UTC ---
Fixed.

[Bug c++/47303] [4.6 Regression] ICE: in varpool_node, at varpool.c:134 with -fabi-version=1

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-01-19 
15:37:02 UTC ---
Author: jakub
Date: Wed Jan 19 15:36:57 2011
New Revision: 169000

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169000
Log:
PR c++/47303
* decl2.c (finish_anon_union): Only call mangle_decl if TREE_STATIC
or DECL_EXTERNAL.

* g++.dg/template/anonunion1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/template/anonunion1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/47303] [4.6 Regression] ICE: in varpool_node, at varpool.c:134 with -fabi-version=1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2011-01-19 
15:49:32 UTC ---
Fixed.

[Bug fortran/47360] New: GENERIC with proc-pointer components as specific functions

[burnus at gcc dot gnu.org]

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

   Summary: GENERIC with proc-pointer components as specific
functions
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Related to PR 47352. 

Both where reported by James in the same thread:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/bbaf59ffd7c372e9


The program in question fails with

 GENERIC :: gen => f1, g1
  1
  Error: Undefined specific binding 'g1' as target of GENERIC 'gen' at (1)


At a glance, the program looks as if it could be valid - though also Crayftn
does not like it (ifort 11 and NAG f95 5.1 do not support GENERIC, yet).


module mytypes
   implicit none
   abstract interface
  function f(x)
 real f, x
  end function f
  function g(x)
 integer g, x
  end function g
   end interface
   type T
  procedure(f),pointer,NOPASS :: f1
  procedure(g),pointer,NOPASS :: g1
  contains
 GENERIC :: gen => f1, g1
   end type T
end module mytypes

module funcs
   implicit none
   contains
  function f(x)
 real f, x
 f = 3*x
  end function f
  function g(x)
 integer g, x
 g = 3*x
  end function g
end module funcs

program test
   use mytypes
   use funcs, f2=>f, g2=>g
   implicit none
   type(T) tau

   tau%f1 => f2
   tau%g1 => g2
   write(*,*) tau%gen(1)
   write(*,*) tau%gen(1.0)
end program test

[Bug fortran/47352] [F03] ICE with proc-pointers in generic procedures

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2011-01-19 
15:58:28 UTC ---
(In reply to comment #0)
> Found at 
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/bbaf59ffd7c372e9#
>  (There is another issue in that thread)

The other issue involving proc-pointer components and a GENERIC type-bound
procedure is now tracked as PR 47360.

[Bug fortran/47360] GENERIC with proc-pointer components as specific functions

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Tobias Burnus  2011-01-19 
16:04:43 UTC ---
"R450 type-bound-generic-stmt
  is GENERIC [ , access-spec ] :: generic-spec => binding-name-list"

"C467 (R450) Each binding-name in binding-name-list shall be the name of
 a specific binding of the type."

"1.3.13 binding name: name given to a specific or generic type-bound procedure
in the type definition (4.5.5)"

And in 4.5.5:
"R447 type-bound-proc-binding is type-bound-procedure-stmt
  or type-bound-generic-stmt
  or final-procedure-stmt"

Hence, the example seems to be invalid as "f1" and "g1" are not type-bound
procedures. -> Close PR.

[Bug target/36861] [4.5/4.6 Regression] boost's compressed avl confuses GCC

[igaztanaga at gmail dot com]

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

--- Comment #40 from Ion Gaztañaga  2011-01-19 
16:07:01 UTC ---
(In reply to comment #39)
> The point with the case in question is that a pointer to a global
> object is computed relative to the address _of an automatic variable_.
> I hope no standard will ever allow that ;)  It might be a simple
> oversight (and thus bug) in Boost AVL though.

Is not an oversight, it's a basic feature to build easy relative addressing to
be used in shared memory and memory mapped files shared between several
processes. A pointer only stores the distance between the "smart pointer" and
the pointee, so it can be mapped in different addresses in several processes.
Support for automatic storage smart pointers is needed just to support
iterators that could be stored in shared memory (thus, storing smart pointers
in shared memory) and also be used by programmers in a loop (automatic
storage).

Until now, this illegal scheme was working in all known compilers (although
outside the standard, I agree). Since the standard does not support shared
memory, if someday shared memory support is added to the standard, it will
surely require some changes to support this widely used relative addressing.
Until then, I agree, this bug report is invalid.

The only issue I would like to know is if this relative addressing scheme for
automatic variables can be used with GCC with some kind of existing annotation,
anything that could force that automatic variable to have an address that could
be used to point to shared memory elements.

Ion

[Bug other/47167] Performance regression in numerical code

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #8 from Richard Guenther  2011-01-19 
16:13:31 UTC ---
Can you check if the following patch solves your problem?

Index: tree-ssa-copyrename.c
===
--- tree-ssa-copyrename.c   (revision 168987)
+++ tree-ssa-copyrename.c   (working copy)
@@ -226,8 +226,11 @@ copy_rename_partition_coalesce (var_map
   ign2 = false;
 }

-  /* Don't coalesce if the two variables are not of the same type.  */
-  if (TREE_TYPE (root1) != TREE_TYPE (root2))
+  /* Don't coalesce if the two variables are not compatible .  */
+  if (!types_compatible_p (TREE_TYPE (root1), TREE_TYPE (root2))
+  || ((TREE_CODE (TREE_TYPE (root1)) == ENUMERAL_TYPE
+  || TREE_CODE (TREE_TYPE (root2)) == ENUMERAL_TYPE)
+ && TREE_TYPE (root1) != TREE_TYPE (root2)))
 {
   if (debug)
fprintf (debug, " : Different types.  No coalesce.\n");


The differences in GIMPLE of the patch do not explain the code-differences
though, so it might be just bad luck that the patch regressed things for
you.  I can see other unwanted differences though.

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu.org

--- Comment #10 from Richard Guenther  2011-01-19 
16:17:50 UTC ---
I think the 2nd patch is more "sound" (that is, it's easier to see what
effects it will have).  Zdenek, do you agree?

[Bug libgcj/45251] [4.6 Regression] Java testsuite regressions on hppa-linux

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther  2011-01-19 
16:19:19 UTC ---
FAILs are gone.  I suppose it was

2011-01-11  Richard Guenther  

PR tree-optimization/47239
* tree-ssa-ccp.c (get_value_from_alignment): Punt for FUNCTION_DECLs.

[Bug tree-optimization/46130] [4.6 Regression] ICE: SIGSEGV in walk_stmt_load_store_addr_ops (gimple.c:4894) with -O2 -fno-tree-dce

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  2011-01-19 
16:29:06 UTC ---
Testcase that needs just -O2 -fno-tree-dce:
static void
foo (__builtin_va_list ap)
{
  __builtin_va_arg (ap, char *)[0];
}

int
bar (__builtin_va_list ap)
{
  foo (ap);
  foo (ap);
}

The issue is that I see nothing that checks the SSA_NAMEs in return_bb PHIs
which originate from the split function are just in phi setting retval and
nothing else.
In this case because of -fno-tree-dce there is a dead PHI which the *.part.0
function doesn't pass through to the caller.

[Bug debug/46101] [4.6 Regression] ICE: in build_abbrev_table, at dwarf2out.c:10333 with -feliminate-dwarf2-dups -g

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Richard Guenther  2011-01-19 
16:31:59 UTC ---
Yes, please open a new bug.  Fixed.

[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment

[matz at gcc dot gnu.org]

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

--- Comment #34 from Michael Matz  2011-01-19 16:39:30 
UTC ---
> As I said in comment #27, gfc_component structs belonging to the type, they
> are shared between target and non-target variants. Thus one cannot set
> inherited target attributes on them.

Yep, that's what I figured eventually :)  The question now is if for:

--
type bar
  integer :: a
  end type bar
  type(bar), pointer :: b
  type(bar)  :: c
--

'b' and 'c' should have the same type.  In other words
should "type(bar),pointer" be a different type vs "type(bar)" already in the
frontend representation for types, or not?  If they would be they wouldn't
have shared components and we would be free to set attributes as we like.

Not knowing much about the several engineering decisions taken while
developing the frontend _I_ personally would have done it this way.  Alas,
no cake for me :)

So, some guidance by the frontend maintainers would be welcome which path
I should take.  Making it more the above suggestion, or really going
with the two backend_decls per entity?  (what I'm worried about with the
two backend_decls is, what in one year we find other reasons why some
attributes need to be different from the base case, then we already need
four backend_delcs)

[Bug target/36861] [4.5/4.6 Regression] boost's compressed avl confuses GCC

[rguenther at suse dot de]

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

--- Comment #41 from rguenther at suse dot de  
2011-01-19 16:40:15 UTC ---
On Wed, 19 Jan 2011, igaztanaga at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
> 
> --- Comment #40 from Ion Gaztañaga  2011-01-19 
> 16:07:01 UTC ---
> (In reply to comment #39)
> > The point with the case in question is that a pointer to a global
> > object is computed relative to the address _of an automatic variable_.
> > I hope no standard will ever allow that ;)  It might be a simple
> > oversight (and thus bug) in Boost AVL though.
> 
> Is not an oversight, it's a basic feature to build easy relative addressing to
> be used in shared memory and memory mapped files shared between several
> processes. A pointer only stores the distance between the "smart pointer" and
> the pointee, so it can be mapped in different addresses in several processes.
> Support for automatic storage smart pointers is needed just to support
> iterators that could be stored in shared memory (thus, storing smart pointers
> in shared memory) and also be used by programmers in a loop (automatic
> storage).

The case in question seems to use random automatic storage to represent
a pointer to unrelated storage.  That is never going to work.  And if
it will ever be required to work all points-to analysis will just
be useless which is not something you want.

> Until now, this illegal scheme was working in all known compilers (although
> outside the standard, I agree). Since the standard does not support shared
> memory, if someday shared memory support is added to the standard, it will
> surely require some changes to support this widely used relative addressing.
> Until then, I agree, this bug report is invalid.
> 
> The only issue I would like to know is if this relative addressing scheme for
> automatic variables can be used with GCC with some kind of existing 
> annotation,
> anything that could force that automatic variable to have an address that 
> could
> be used to point to shared memory elements.

No, there is no way to do that.  Sorry, but you really have to
re-design this thing to be standard conformant.

Richard.

[Bug lto/46798] [4.6 Regression] invalid conversion in gimple call; verify_stmts failed

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug c++/46807] [4.6 Regression] internal compiler error: in synthesized_method_walk

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug middle-end/46900] [4.6 Regression] 50% slowdown when linking with LTO in a single step

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.01.19 16:48:38
 Ever Confirmed|0   |1

--- Comment #8 from Richard Guenther  2011-01-19 
16:48:38 UTC ---
PR42445 has been fixed - does this bug still reproduce?

[Bug lto/46911] [4.6 Regression] ICE: SIGSEGV in add_name_and_src_coords_attributes (dwarf2out.c:17792) with -flto -g

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-01-19 
16:53:11 UTC ---
(In reply to comment #1)
> When dwarf2out_abstract_function is called on MAIN__, it doesn't have
> DECL_INITIAL set when in lto1 (compared to f951), the BLOCK tree is simply not
> present, which both causes incomplete debug information and for Fortran COMMON
> blocks ICEs, as it relies on those to be actually present.  P4 as it only
> affects Fortran, but if -flto -g is ever meant to be usable, the BLOCK trees
> need to be streamed out and preserved.  It seems output_function calls:
>   /* Output DECL_INITIAL for the function, which contains the tree of
>  lexical scopes.  */
>   lto_output_tree (ob, DECL_INITIAL (function), true);
> but for inlines output_function isn't called.

That's true.  Inlines would be reachable via the block trees abstract
origins, right?  We do stream that, so the only thing missing is
associating it with the function-decl ... (maybe we can do that
when reading the BLOCK and its context is a FUNCTION_DECL?)

[Bug lto/46911] [4.6 Regression] ICE: SIGSEGV in add_name_and_src_coords_attributes (dwarf2out.c:17792) with -flto -g

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-01-19 
16:55:55 UTC ---
Yeah, all the inlines should be BLOCK_ABSTRACT_ORIGIN of some BLOCK that is
being streamed, so in theory all of them should be already streamed, just
DECL_INITIAL is not filled in.

[Bug tree-optimization/46130] [4.6 Regression] ICE: SIGSEGV in walk_stmt_load_store_addr_ops (gimple.c:4894) with -O2 -fno-tree-dce

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2011-01-19 
16:59:59 UTC ---
Yet another testcase:
extern int bar (int);

static int foo (int x)
{
  int z, w;
  if (x <= 1024)
{
  z = 16;
  w = 17;
}
  else
{
  bar (bar (bar (bar (bar (bar (bar (bar (bar (16);
  if (x > 131072)
w = 19;
  else
w = 21;
  z = 32;
}
  w = w + 121;
  return z;
}

int
baz (int x)
{
  return foo (x + 6) + foo (x + 15) + foo (x + 24);
}

This one shows one PHI node for retval we handle correctly and one we don't.
What we perhaps could handle is if the phi argument in the other PHI is the
same in all the edges from split_bbs and originates outside of the split bbs,
but probably it isn't worth handling it.

[Bug lto/46911] [4.6 Regression] ICE: SIGSEGV in add_name_and_src_coords_attributes (dwarf2out.c:17792) with -flto -g

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-01-19 
17:10:31 UTC ---
We already do

  /* We re-compute BLOCK_SUBBLOCKS of our parent here instead
 of streaming it.  For non-BLOCK BLOCK_SUPERCONTEXTs we still
 stream the child relationship explicitly.  */
  if (BLOCK_SUPERCONTEXT (expr)
  && TREE_CODE (BLOCK_SUPERCONTEXT (expr)) == BLOCK)
{
  BLOCK_CHAIN (expr) = BLOCK_SUBBLOCKS (BLOCK_SUPERCONTEXT (expr));
  BLOCK_SUBBLOCKS (BLOCK_SUPERCONTEXT (expr)) = expr;
}

so adding a

  if (BLOCK_SUPERCONTEXT (expr)
  && TREE_CODE (BLOCK_SUPERCONTEXT (expr)) == FUNCTION_DECL)
DECL_INITIAL (BLOCK_SUPERCONTEXT (expr)) = expr;

shouldn't be too bad - but it does not fixe the testcase ... (but
DECL_INITIAL is now filled in correctly - I bet without VAR_DECLs
though).

[Bug debug/47361] New: ICE: in build_abbrev_table, at dwarf2out.c:10477 with -g -feliminate-dwarf2-dups

[zsojka at seznam dot cz]

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

   Summary: ICE: in build_abbrev_table, at dwarf2out.c:10477 with
-g -feliminate-dwarf2-dups
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: do...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 23030
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23030
reduced testcase

+++ This bug was initially created as a clone of Bug #46101 +++

Compiler output:
$ gcc pr47361.C -std=c++0x -g -feliminate-dwarf2-dups
pr47361.C:8:4: internal compiler error: in build_abbrev_table, at
dwarf2out.c:10477
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r168990 - crash
4.5 - doesn't know nullptr

[Bug other/47167] Performance regression in numerical code

[mar...@mpa-garching.mpg.de]

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

--- Comment #9 from Martin Reinecke  2011-01-19 
17:26:31 UTC ---
(In reply to comment #8)
> Can you check if the following patch solves your problem?

Yes, this patch gets performance back to normal on the 4.5 branch and on trunk.
Great!

> The differences in GIMPLE of the patch do not explain the code-differences
> though, so it might be just bad luck that the patch regressed things for
> you.  I can see other unwanted differences though.

I would of course be happy if the code generation would be less "erratic", and
if the nice performance I'm seeing does not depend on my luck ;)
So if I can do anything to help optimizing this kind of code more consistently,
please let me know! Of course, I'm more into numerics than into compiler
writing ...

[Bug c/47362] New: genconstants.c:68: undefined reference to `_ __chkstk_ms' on 01/15/2011 snapshot

[michael.a.richmond at nasa dot gov]

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

   Summary: genconstants.c:68: undefined reference to `_
__chkstk_ms' on 01/15/2011 snapshot
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michael.a.richm...@nasa.gov
  Host: i686-pc-cygwin
Target: i686-pc-cygwin
 Build: i686-pc-cygwin


When I compile the gcc 4.6 snapshot of 01/15/2011 on Cygwin I get the message:

build/genconstants.o: In function `print_enum_type':
/home/mrichmon/gcc-4.6-20110115/gcc/genconstants.c:68: undefined reference to
`_
__chkstk_ms'

This does not occur when compiling earlier snapshots of gcc 4.6 on Cygwin. It
does not occur when compiling the snapshot of 01/15/2011 on other platforms.

[Bug tree-optimization/46130] [4.6 Regression] ICE: SIGSEGV in walk_stmt_load_store_addr_ops (gimple.c:4894) with -O2 -fno-tree-dce

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2011-01-19 
17:38:25 UTC ---
Created attachment 23031
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23031
gcc46-pr46130.patch

Untested fix.

[Bug testsuite/41146] FAIL: gcc.target/powerpc/asm-es-2.c scan-assembler *

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Dominique d'Humieres  2011-01-19 
17:38:34 UTC ---
Closing as fixed. Thanks for the commit.

[Bug libgcj/44415] [4.6 regression] gmp multilib support broke bootstrap with static libgmp

[mrs at gcc dot gnu.org]

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

m...@gcc.gnu.org  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org

--- Comment #5 from mrs at gcc dot gnu.org  2011-01-19 
18:10:01 UTC ---
If we are to document bugs, please, let's include a bug number for people to
reference so that they can see when the problem is fixed.

[Bug fortran/47348] wrong string length with array constructor

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

Summary|substring with len_trim in  |wrong string length with
   |array constructor   |array constructor

--- Comment #3 from Thomas Koenig  2011-01-19 
19:14:04 UTC ---
Reduced test case:

program main
  implicit none
  character(len=*), parameter :: fmt='(2(A,"|"))'
  integer :: i
  character(len=4) :: q

  q = 'yy'
  i = 2

  print fmt, (/ trim(q), 'ae' /)//'c'
  print fmt, (/ q(1:i), 'ae' /)//'c'

end program main

This prints

yyc|aec|
yy  c|ae  c|

so the string length of the array constructor is wrong.

[Bug rtl-optimization/47166] [4.5.2/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb

[bernds at gcc dot gnu.org]

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

--- Comment #14 from Bernd Schmidt  2011-01-19 
19:31:20 UTC ---
(In reply to comment #13)
> Please consider reverting the reload change on the branch.  I don't think we
> want to keep fiddling with reload there.

I don't see how this makes any sense. We've identified two bugs in reload, both
leading to incorrect code, and you'd rather revert the fix for one than fix
both?

[Bug gcov-profile/47363] New: value-profile.c produces incorrect error message when *count > *all

[asharif at gcc dot gnu.org]

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

   Summary: value-profile.c produces incorrect error message when
*count > *all
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: asha...@gcc.gnu.org


Created attachment 23032
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23032
Patch that adds a helpful error message when the profile is corrupted.

When a profile is corrupted and *count > *all (in value-prof.c) around line
473, an incorrect message is generated. This message reads:

profiler overall count (%d) does not match BB count (%d)

The integers in parentheses are actually equal so the message is confusing to
the user.

There should be a better error message generated in this case, pointing the
user to what went wrong.

I am attaching a patch that fixes this (I'll also be sending out an email to
the mailing list).

[Bug rtl-optimization/47166] [4.5.2/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb

[ebotcazou at gcc dot gnu.org]

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

--- Comment #15 from Eric Botcazou  2011-01-19 
19:44:44 UTC ---
> I don't see how this makes any sense. We've identified two bugs in reload, 
> both
> leading to incorrect code, and you'd rather revert the fix for one than fix
> both?

Yes, because the first one wasn't a regression and fixing the second may well
cause a third to pop up, you never know with reload.  This is called RM...

[Bug c++/46807] [4.6 Regression] internal compiler error: in synthesized_method_walk

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2011-01-19 
19:45:17 UTC ---
Created attachment 23033
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23033
pr46807.ii

Even further reduced testcase (and this time one that compiles without errors
with g++ 4.5).

[Bug libstdc++/36104] [4.3/4.4/4.5/4.6 Regression] gnu-versioned-namespace is broken

[bkoz at gcc dot gnu.org]

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

--- Comment #12 from Benjamin Kosnik  2011-01-19 
20:00:52 UTC ---
Author: bkoz
Date: Wed Jan 19 20:00:47 2011
New Revision: 169021

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169021
Log:
2011-01-19  Benjamin Kosnik  

PR libstdc++/36104 part two
* include/bits/hashtable.h: Revert to non-nested macro usage.
* include/bits/hashtable_policy.h: Same.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/hashtable.h
trunk/libstdc++-v3/include/bits/hashtable_policy.h

[Bug c++/47338] [4.5 Regression] cc1plus returns exit code 5

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|4.5.3   |4.6.0

--- Comment #6 from Andrew Pinski  2011-01-19 
20:10:29 UTC ---
(In reply to comment #5)
> (what's the default on mingw32 for that?)
The default stack under Windows is low.  
This was all fixed with:
r167400 | davek | 2010-12-02 15:30:47 -0800 (Thu, 02 Dec 2010) | 6 lines

* mh-cygwin (LDFLAGS): Turn up stack allocation to 12MB.
(BOOT_LDFLAGS): Add matching stack size flag.
* mh-mingw (LDFLAGS): Likewise.
(BOOT_LDFLAGS): Likewise.

[Bug rtl-optimization/41619] [4.4/4.5/4.6 regression] ICE in insert_save (caller-save.c) for SPEC CPU2000's 252.eon

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
  Known to fail||

--- Comment #7 from Jeffrey A. Law  2011-01-19 20:15:32 
UTC ---
Looking at it

[Bug rtl-optimization/47166] [4.5.2/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb

[hp at gcc dot gnu.org]

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

--- Comment #16 from Hans-Peter Nilsson  2011-01-19 
20:30:14 UTC ---
(In reply to comment #15)
>  the first one wasn't a regression and fixing the second may well
> cause a third to pop up, you never know with reload.  This is called RM...

FWIW, you'd then be in danger of regressing 41085.
I have to say it won't be very RM:y to proactively unfix two bugs just because
it's reload, given two separate fixes...

[Bug c++/46890] [4.6 Regression] Failed to compile scummvm's player_v4a.cpp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 AssignedTo|jakub at gcc dot gnu.org|froydnj at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  2011-01-19 
20:40:31 UTC ---
Reassigning back to Nathan, he apparently posted a patch at:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01398.html
with feedback at:
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00252.html

[Bug target/47364] New: [x32] internal compiler error: in emit_move_insn, at expr.c:3355

[hjl.tools at gmail dot com]

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

   Summary: [x32] internal compiler error: in emit_move_insn, at
expr.c:3355
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On x32 branch, revision 169022 gave me:

[hjl@gnu-6 ilp32-6]$ cat l.i
static unsigned char foo[256];

arc4_init(void)
{
  int n;

  for (n = 0; n < 256; n++)
foo[n] = n;
}
...

Starting program: /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/cc1
-fpreprocessed l.i -quiet -dumpbase l.i -mx32 -mtune=generic -march=x86-64
-auxbase-strip l.s -O -version -fPIC -o l.s
GNU C (GCC) version 4.6.0 20110119 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.1 20100924 (Red Hat 4.5.1-4), GMP version
4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.6.0 20110119 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.1 20100924 (Red Hat 4.5.1-4), GMP version
4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 907bc1978bdfb9cacc592629d3ab71fe

Breakpoint 1, fancy_abort (
file=0x11f1068 "/export/gnu/import/git/gcc-x32/gcc/expr.c", line=3355, 
function=0x11f2526 "emit_move_insn")
at /export/gnu/import/git/gcc-x32/gcc/diagnostic.c:893
893  internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) bt
#0  fancy_abort (file=0x11f1068 "/export/gnu/import/git/gcc-x32/gcc/expr.c", 
line=3355, function=0x11f2526 "emit_move_insn")
at /export/gnu/import/git/gcc-x32/gcc/diagnostic.c:893
#1  0x006f074b in emit_move_insn (x=0x71af4bc0, y=0x71af4aa0)
at /export/gnu/import/git/gcc-x32/gcc/expr.c:3354
#2  0x00cda2b9 in ix86_legitimize_address (x=0x71af81f8, 
oldx=0x71af81c8, mode=QImode)
at /export/gnu/import/git/gcc-x32/gcc/config/i386/i386.c:12952
#3  0x009ed580 in default_addr_space_legitimize_address (
x=0x71af81f8, oldx=0x71af81c8, mode=QImode, as=0 '\000')
at /export/gnu/import/git/gcc-x32/gcc/targhooks.c:1136
#4  0x006d416b in memory_address_addr_space (mode=QImode, 
x=0x71af81f8, as=0 '\000')
at /export/gnu/import/git/gcc-x32/gcc/explow.c:457
#5  0x0070ba0e in expand_expr_real_1 (exp=0x71af60a0, target=0x0, 
tmode=VOIDmode, modifier=EXPAND_WRITE, alt_rtl=0x0)
at /export/gnu/import/git/gcc-x32/gcc/expr.c:8645
#6  0x00704be3 in expand_expr_real (exp=0x71af60a0, target=0x0, 
tmode=VOIDmode, modifier=EXPAND_WRITE, alt_rtl=0x0)
at /export/gnu/import/git/gcc-x32/gcc/expr.c:7214
#7  0x006e7863 in expand_expr (exp=0x71af60a0, target=0x0, 
mode=VOIDmode, modifier=EXPAND_WRITE)
at /export/gnu/import/git/gcc-x32/gcc/expr.h:422

[Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  2011-01-19 
20:44:27 UTC ---
> I know this is sort of a contrived case but seems that gfortran is getting
> confused in this case leading to syntactically invalid assembler.

I don't see the invalid assembler on x86_64-apple-darwin10 and
powerpc-apple-darwin9 for trunk (4.6), 4.50, and 4.4.4. However gfortran is
indeed confused by the code as shown by the following modification:

RECURSIVE FUNCTION MAX(A, B, i) RESULT(K)
  real i
  i = i + 1
  IF (B >= 0) THEN
 K = MAX(A+1, B-1, i)
  ELSE
 K = A
  END IF
END
RECURSIVE FUNCTION myMAX(A, B, i) RESULT(K)
  real i
  i = i + 1
  IF (B >= 0) THEN
 K = myMAX(A+1, B-1, i)
  ELSE
 K = A
  END IF
END
external max
a = 0
b = 0
i = max(3.2,0.2, a)
j = mymax(3.2,0.2, b)
print *, i, j, a, b
a = 0
b = 0
i = max(3.2,2.2, a)
j = mymax(3.2,2.2, b)
print *, i, j, a, b
end
[macbook] f90/bug% gfc pr47359_db_3.f90
[macbook] f90/bug% a.out
   4   4   1.000   2.000
   4   6   1.000   4.000

where I had to declare 'i' REAL in order to avoid a compilation error and
clearly the external MAX is called, but only once apparently because the call
to MAX in MAX is a call to the intrinsic. g95 gives

 4 4 2. 2.
 6 6 4. 4.

[Bug tree-optimization/47190] [4.5/4.6 Regression] ICE: in function_and_variable_visibility, at ipa.c:934 with static weakref variable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org

[Bug c++/47172] [4.6 Regression] [C++0x] cannot call member function without object

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org

[Bug tree-optimization/47193] [4.6 Regression] ICE: in function_and_variable_visibility, at ipa.c:857 with static var weakref'd to other weakref'd static var

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org

[Bug c++/47198] [4.5/4.6 Regression] [C++0x] ICE: tree check: expected var_decl or function_decl, have template_decl in check_bases_and_members, at cp/class.c:4654 on invalid code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org

[Bug target/47364] [x32] internal compiler error: in emit_move_insn, at expr.c:3355

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  2011-01-19 
20:53:19 UTC ---
Author: hjl
Date: Wed Jan 19 20:53:14 2011
New Revision: 169029

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169029
Log:
Convert to Pmode if needed in ix86_legitimize_address.

gcc/

2011-01-19  H.J. Lu  

PR target/47364
* config/i386/i386.c (ix86_legitimize_address): Convert to
Pmode if needed.

gcc/testsuite/

2011-01-19  H.J. Lu  

PR target/47364
* gcc.target/i386/pr47364.c: New.

Added:
branches/x32/gcc/testsuite/ChangeLog.x32
branches/x32/gcc/testsuite/gcc.target/i386/pr47364.c
Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/config/i386/i386.c

[Bug c++/47199] [4.6 Regression] [C++0x] ICE: expected class 'type', have 'declaration' (function_decl) in same_type_ignoring_top_level_qualifiers_p, at cp/typeck.c:1407 with -fno-elide-constructors

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org

[Bug c++/47206] [4.6 Regression] [C++0x] ICE: SIGSEGV in cp_tree_equal (tree.c:2150) with -fno-elide-constructors

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org

[Bug c++/47207] [4.6 Regression] [C++0x] ICE: in decl_constant_var_p, at cp/decl2.c:3563 on invalid code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org

[Bug c++/47208] [4.6 Regression] [C++0x] ICE: in decl_constant_var_p, at cp/decl2.c:3563 with missing #include

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org

[Bug tree-optimization/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org

[Bug target/47312] [4.6 Regression] ICE: in expand_ternary_op, at optabs.c:656 with -flto -mno-sse -mxop and __builtin_fmaf()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/47291] [4.6 Regression] ICE: SIGSEGV in size_binop_loc (fold-const.c:1427) with -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org

[Bug target/47364] [x32] internal compiler error: in emit_move_insn, at expr.c:3355

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2011-01-19 21:02:01 
UTC ---
Another one. On x32 branch, revision 169029 gave me:

[hjl@gnu-6 ilp32-7]$ cat x.c
extern __SIZE_TYPE__ strlen (const char *);
void foo (char *, const char *);
int bar (const char *prefix)
{
char buff[256];
foo (buff, prefix);
return strlen(buff);
}
[hjl@gnu-6 ilp32-7]$ make
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O2   x.c
x.c: In function ‘bar’:
x.c:7:18: internal compiler error: in emit_move_insn, at expr.c:3355
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [x.s] Error 1
[hjl@gnu-6 ilp32-7]$ 

(gdb) r
Starting program: /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/cc1
-fpreprocessed foo.i -quiet -dumpbase foo.i -mx32 -mtune=generic -march=x86-64
-auxbase-strip foo.s -O2 -version -o foo.s
GNU C (GCC) version 4.6.0 20110119 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.1 20100924 (Red Hat 4.5.1-4), GMP version
4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.6.0 20110119 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.1 20100924 (Red Hat 4.5.1-4), GMP version
4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 2521805caa85b3824657bbc223b7b9f6

Breakpoint 1, fancy_abort (
file=0x11f1128 "/export/gnu/import/git/gcc-x32/gcc/expr.c", line=3355, 
function=0x11f25e6 "emit_move_insn")
at /export/gnu/import/git/gcc-x32/gcc/diagnostic.c:893
893  internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) bt
#0  fancy_abort (file=0x11f1128 "/export/gnu/import/git/gcc-x32/gcc/expr.c", 
line=3355, function=0x11f25e6 "emit_move_insn")
at /export/gnu/import/git/gcc-x32/gcc/diagnostic.c:893
#1  0x006f074b in emit_move_insn (x=0x71c92fc0, y=0x71c92d60)
at /export/gnu/import/git/gcc-x32/gcc/expr.c:3354
#2  0x00cef39f in ix86_expand_strlen (out=0x71c92fc0, 
src=0x71af01b0, eoschar=0x71ba3470, align=0x71ba34f0)
at /export/gnu/import/git/gcc-x32/gcc/config/i386/i386.c:21664
#3  0x00ecf575 in gen_strlensi (operand0=0x71c92fc0, 
operand1=0x71af01b0, operand2=0x71ba3470, operand3=0x71ba34f0)
at /export/gnu/import/git/gcc-x32/gcc/config/i386/i386.md:16173
#4  0x005ae5bd in expand_builtin_strlen (exp=0x71a985e8, 
target=0x71c92fc0, target_mode=SImode)
at /export/gnu/import/git/gcc-x32/gcc/builtins.c:3429
#5  0x005bb501 in expand_builtin (exp=0x71a985e8, 
target=0x71c92fc0, subtarget=0x0, mode=SImode, ignore=0)
at /export/gnu/import/git/gcc-x32/gcc/builtins.c:6120
#6  0x007102aa in expand_expr_real_1 (exp=0x71a985e8, 
target=0x71c92fc0, tmode=SImode, modifier=EXPAND_NORMAL, 
alt_rtl=0x7fffce00) at /export/gnu/import/git/gcc-x32/gcc/expr.c:9300
#7  0x00704b9e in expand_expr_real (exp=0x71a985e8, 
target=0x71c92fc0, tmode=SImode, modifier=EXPAND_NORMAL, 
alt_rtl=0x7fffce00) at /export/gnu/import/git/gcc-x32/gcc/expr.c:7206
---Type  to continue, or q  to quit---
#8  0x006f5eb7 in store_expr (exp=0x71a985e8, 
target=0x71c92fc0, call_param_p=0, nontemporal=0 '\000')
at /export/gnu/import/git/gcc-x32/gcc/expr.c:4674
#9  0x006f437b in expand_assignment (to=0x71aa8160, 
from=0x71a985e8, nontemporal=0 '\000')
at /export/gnu/import/git/gcc-x32/gcc/expr.c:4447
#10 0x0060a896 in expand_call_stmt (stmt=0x71ba8380)
at /export/gnu/import/git/gcc-x32/gcc/cfgexpand.c:1914
#11 0x0060a997 in expand_gimple_stmt_1 (stmt=0x71ba8380)
at /export/gnu/import/git/gcc-x32/gcc/cfgexpand.c:1949
#12 0x0060b046 in expand_gimple_stmt (stmt=0x71ba8380)
at /export/gnu/import/git/gcc-x32/gcc/cfgexpand.c:2108
#13 0x00611b18 in expand_gimple_basic_block (bb=0x71a941a0)
at /export/gnu/import/git/gcc-x32/gcc/cfgexpand.c:3570
#14 0x006138e1 in gimple_expand_cfg ()
at /export/gnu/import/git/gcc-x32/gcc/cfgexpand.c:4053
#15 0x008f985f in execute_one_pass (pass=0x17aeda0)
at /export/gnu/import/git/gcc-x32/gcc/passes.c:1561
#16 0x008f9a4e in execute_pass_list (pass=0x17aeda0)
at /export/gnu/import/git/gcc-x32/gcc/passes.c:1616
#17 0x00a82714 in tree_rest_of_compilation (fndecl=0x71aa6100)
at /export/gnu/import/git/gcc-x32/gcc/tree-optimize.c:422
#18 0x00d228c9 in cgraph_expand_function (node=0x71aaa000)
---Type  to continue, or q  to quit---
at /e

[Bug fortran/47352] [F03] ICE with proc-pointers in generic procedures

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |

--- Comment #3 from janus at gcc dot gnu.org 2011-01-19 21:21:30 UTC ---
Simple patch to avoid the ICE:

Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 168973)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -4827,7 +4827,7 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * e
 }

   if (expr->expr_type == EXPR_FUNCTION
-  && ((expr->value.function.esym
+  && ((expr->value.function.esym && expr->value.function.esym->result
&& expr->value.function.esym->result->attr.pointer
&& !expr->value.function.esym->result->attr.dimension)
   || (!expr->value.function.esym

[Bug tree-optimization/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #6 from Jakub Jelinek  2011-01-19 
21:29:07 UTC ---
Mine.

[Bug c++/47211] ICE: in cp_build_addr_expr_1, at cp/typeck.c:4866 with -fms-extensions

[zsojka at seznam dot cz]

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

--- Comment #4 from Zdenek Sojka  2011-01-19 21:30:38 
UTC ---
Created attachment 23034
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23034
different crash

This crashes with different message:

$ gcc -fms-extensions pr47211-2.C 
pr47211-2.C: In function 'void foo(void (A::*)())':
pr47211-2.C:9:9: internal compiler error: in build_ptrmemfunc, at
cp/typeck.c:7047
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

When foo() is not a template, it ICEs in cp_build_addr_expr_1, at
cp/typeck.c:4866

[Bug middle-end/47344] [4.3/4.4/4.5/4.6 Regression][meta-bug] GCC gets slower and uses more memory

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org

[Bug target/47364] [x32] internal compiler error: in emit_move_insn, at expr.c:3355

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  2011-01-19 
21:38:37 UTC ---
Author: hjl
Date: Wed Jan 19 21:38:32 2011
New Revision: 169032

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169032
Log:
Properly handle Pmode != ptr_mode when expanding builtin strlen.

gcc/

2011-01-19  H.J. Lu  

PR target/47364
* builtins.c (expand_builtin_strlen): Convert to Pmode if PAT
isn't in Pmode.

* config/i386/i386.c (ix86_expand_strlen): Handle GET_MODE (out)
!= Pmode.

gcc/testsuite/

2011-01-19  H.J. Lu  

PR target/47364
* gcc.target/i386/pr47364-2.c: New.

Added:
branches/x32/gcc/testsuite/gcc.target/i386/pr47364-2.c
Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/builtins.c
branches/x32/gcc/config/i386/i386.c
branches/x32/gcc/testsuite/ChangeLog.x32

[Bug c/22297] [4.3/4.4/4.5/4.6 Regression] missing uninitialized warning (builtin functions)

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||nicola at gcc dot gnu.org
  Known to work||4.6.0
 Resolution||FIXED
   Target Milestone|4.3.6   |4.6.0

--- Comment #11 from Nicola Pero  2011-01-19 
21:40:14 UTC ---
This works for me with GCC 4.6.0 --

[nicola@lampone ~]$ cat x.c
#include 

int g(char *);
int f(void)
{
  char *s;
  strcpy(s,s);
  return g(s);
}
[nicola@lampone ~]$ gcc x.c -Wall -c -O2
x.c: In function ‘f’:
x.c:8:3: warning: ‘s’ is used uninitialized in this function [-Wuninitialized]
[nicola@lampone ~]$

The same doesn't work with GCC 4.1.2, where the same gcc command generates
no warnings at all.

So it looks like the problem has been fixed :-)

Thanks

[Bug debug/47079] [4.6 Regression] FAIL: gcc.dg/guality/nrv-1.c

[aoliva at gcc dot gnu.org]

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

--- Comment #3 from Alexandre Oliva  2011-01-19 
22:00:08 UTC ---
Author: aoliva
Date: Wed Jan 19 22:00:00 2011
New Revision: 169034

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169034
Log:
PR debug/47079
PR debug/46724
* function.c (instantiate_expr): Instantiate incoming rtl of
implicit arguments, and recurse on VALUE_EXPRs.
(instantiate_decls): Instantiate rtl and VALUE_EXPR of result.
* var-tracking.c (adjust_mems): Reject virtual_incoming_args_rtx.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c
trunk/gcc/var-tracking.c

[Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location

[aoliva at gcc dot gnu.org]

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

--- Comment #13 from Alexandre Oliva  2011-01-19 
22:00:09 UTC ---
Author: aoliva
Date: Wed Jan 19 22:00:00 2011
New Revision: 169034

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169034
Log:
PR debug/47079
PR debug/46724
* function.c (instantiate_expr): Instantiate incoming rtl of
implicit arguments, and recurse on VALUE_EXPRs.
(instantiate_decls): Instantiate rtl and VALUE_EXPR of result.
* var-tracking.c (adjust_mems): Reject virtual_incoming_args_rtx.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c
trunk/gcc/var-tracking.c

[Bug middle-end/46900] [4.6 Regression] 50% slowdown when linking with LTO in a single step

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #9 from Tobias Burnus  2011-01-19 
22:03:58 UTC ---
Seems to be FIXED.

[Bug debug/47079] [4.6 Regression] FAIL: gcc.dg/guality/nrv-1.c

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Alexandre Oliva  2011-01-19 
22:06:35 UTC ---
Fixed

[Bug debug/46240] [4.6 Regression] ice in maybe_register_def

[aoliva at gcc dot gnu.org]

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

--- Comment #7 from Alexandre Oliva  2011-01-19 
22:07:16 UTC ---
Author: aoliva
Date: Wed Jan 19 22:07:14 2011
New Revision: 169035

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169035
Log:
gcc/ChangeLog:
PR debug/46240
* tree-into-ssa.c (maybe_register_def): Do not attempt to add
debug bind stmt on merge edges.
gcc/testsuite/ChangeLog:
PR debug/46240
* g++.dg/debug/pr46240.cc: New.

Added:
trunk/gcc/testsuite/g++.dg/debug/pr46240.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-into-ssa.c

[Bug fortran/47034] TRANSFER of C_PTR: Components of structure constructor are PRIVATE

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2011-01-19 
22:08:00 UTC ---
Cf. also
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/808e9fca919694d7#

[Bug debug/46240] [4.6 Regression] ice in maybe_register_def

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Alexandre Oliva  2011-01-19 
22:11:33 UTC ---
Fixed

[Bug tree-optimization/47365] New: [4.5 Regression] wrong code with -O -ftree-pre

[zsojka at seznam dot cz]

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

   Summary: [4.5 Regression] wrong code with -O -ftree-pre
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 23035
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23035
reduced testcase

Reported by Vegard Nossum at IRC.

Output:
$ gcc-4.5 -O -ftree-pre testcase.c
$ ./a.out 
Aborted

In the testcase.c.092t.pre dump, there is:
...
:
  D.2739_4 = b.a[0].i;
  i.0_5 = i;
  if (D.2739_4 != i.0_5)
goto ;
  else
goto ;

:
  b.a[0] = b.a[1];
  b.a[1].i = D.2739_4;
  pretmp.3_6 = b.a[1].i;
  goto ;

:
...
:

:
  # prephitmp.4_8 = PHI 
  D.2739_9 = prephitmp.4_8;
  D.2739_9 = prephitmp.4_8;
  if (D.2739_9 == 0)
goto ;
...

Problematic line is
  pretmp.3_6 = b.a[1].i;
which reads the new value of "b.a[1].i". It should either happen one line
earlier, or it should read "b.a[0].i".

It seems that the fact "b.a[0] = b.a[1]" overwrites "b.a[0].i" is ignored.

Of couse I can be wrong.

Tested revisions:
r169006 - OK
4.5 r168785 - fail
4.4 r168785 - OK

[Bug rtl-optimization/47166] [4.5.2/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb

[ebotcazou at gcc dot gnu.org]

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

--- Comment #17 from Eric Botcazou  2011-01-19 
22:45:20 UTC ---
> I have to say it won't be very RM:y to proactively unfix two bugs just because
> it's reload, given two separate fixes...

Well, the second is still not fixed as of this writing, that's why I suggested
reverting the problematic first fix in the first place.  As for "just because
it's reload", yes, that's precisely the point; patching reload is always risky.

[Bug c++/47291] [4.6 Regression] ICE: SIGSEGV in size_binop_loc (fold-const.c:1427) with -g

[dodji at gcc dot gnu.org]

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

--- Comment #4 from Dodji Seketeli  2011-01-19 
22:58:03 UTC ---
Author: dodji
Date: Wed Jan 19 22:57:47 2011
New Revision: 169036

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169036
Log:
Fix PR c++/47291

gcc/
PR c++/47291
* dwarf2out.c (generic_type_p, schedule_generic_params_dies_gen)
(gen_scheduled_generic_parms_dies): New functions.
(gen_struct_or_union_type_die): Schedule template parameters DIEs
generation for the end of CU compilation.
(dwarf2out_finish): Generate template parameters DIEs here.

gcc/testsuite/

PR c++/47291
* g++.dg/debug/dwarf2/template-params-10.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/template-params-10.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/47291] [4.6 Regression] ICE: SIGSEGV in size_binop_loc (fold-const.c:1427) with -g

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Dodji Seketeli  2011-01-19 
22:59:39 UTC ---
Fixed in trunk (4.6)

[Bug tree-optimization/47366] New: [4.6 Regression] ICE: verify_flow_info failed: missing REG_EH_REGION note in the end of bb 3 with -fnon-call-exceptions -fno-tree-ccp -fno-tree-forwprop

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: verify_flow_info failed: missing
REG_EH_REGION note in the end of bb 3 with
-fnon-call-exceptions -fno-tree-ccp -fno-tree-forwprop
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 23036
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23036
reduced testcase

Compiler output:
$ gcc -O -fnon-call-exceptions -fno-tree-ccp -fno-tree-forwprop testcase.C 
testcase.C: In function 'void foo()':
testcase.C:18:1: error: missing REG_EH_REGION note in the end of bb 3
testcase.C:18:1: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r169006 - crash
4.5 r168785 - OK