[Bug c++/49260] [C++0x] lambda-eh2.C fails execution

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  2011-06-28 
07:13:30 UTC ---
> Should be fixed on trunk now.

Yes, it is, thanks.  Do you plan to backport the fix to the 4.6 branch?

[Bug ada/49557] Building the GCC compiler suite fails on a Makefile concerning Ada

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.06.28 07:27:30
 CC||ebotcazou at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Eric Botcazou  2011-06-28 
07:27:30 UTC ---
What happens if you use an absolute path to the configure script instead?

[Bug c++/49558] Compiling gcc-3.4.5 source code on MAC OS X 10.6.3 gives an error.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Andrew Pinski  2011-06-28 
07:41:57 UTC ---
GCC 3.4.5 is no longer supported and really did not have support for
x86-darwin.  Please use a newer version of GCC.

[Bug c/49560] New: -fexec-charset=IBM-1047 makes -Wformat report incorrect warnings

[jphartmann at gmail dot com]

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

   Summary: -fexec-charset=IBM-1047 makes -Wformat report
incorrect warnings
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jphartm...@gmail.com


Created attachment 24612
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24612
Preprocessor output from printf

It looks as if the translated form of the format string is used.  Removing the
substitution parameter clears the warning.  ASCII % (0x37) is not likely to be
in any string that is converted to EBCDIC.

[/home/john/src/cmsh/390] CFLAGS=-Wall make hlo
cc -Wallhlo.c   -o hlo
[/home/john/src/cmsh/390] rm hlo
[/home/john/src/cmsh/390] CFLAGS="-fexec-charset=IBM-1047 -Wall" make hlo
cc -fexec-charset=IBM-1047 -Wallhlo.c   -o hlo
hlo.c: In function 'main':
hlo.c:17: warning: spurious trailing '%' in format
hlo.c:17: warning: too many arguments for format


[/home/john/src/cmsh/390] gcc --version
gcc (GCC) 4.4.5 20101112 (Red Hat 4.4.5-2)

Don't know how RedHat configured the compiler.

And also with a 4.6.0 I compiled from unmodified source.
--with-gnu-as --with-gnu-ld --prefix=/home/john/pool/360/root/usr
--with-sysroot=/home/john/pool/360/root --target=s390x-ibm-linux
--enable-languages=c --with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr
--disable-libgomp --disable-threads --disable-tls --disable-libada
--disable-libssp --disable-shared --without-headers --disable-lto --disable-nls

[/home/john/src/cmsh/390] uname -a
Linux bigserv 2.6.34.8-68.fc13.x86_64 #1 SMP Thu Feb 17 15:03:58 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux

[Bug libstdc++/49561] New: gcc does not meet the standard for std::list container

[yoch.melka at gmail dot com]

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

   Summary: gcc does not meet the standard for std::list container
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yoch.me...@gmail.com


I realized that the complexity of std::list::size() is O(n), not O(1).

This does not conform to standard. The standard states that size() function is
in constant time for alls containers. So, the behavior of gcc is not as
expected.

This also affects parts of std::list::splice() function, as mentioned in the
last drat (n3242 - 23.3.5.5):

[quote]
1 Since lists allow fast insertion and erasing from the middle of a list,
certain operations are provided specifically
for them.
2 list provides three splice operations that destructively move elements from
one list to another.[...]

void splice(const_iterator position, list& x) noexcept;
void splice(const_iterator position, list&& x) noexcept;
[...]
4 Effects: Inserts the contents of x before position and x becomes empty.
Pointers and references to
the moved elements of x now refer to those same elements but as members of
*this. Iterators referring
to the moved elements will continue to refer to their elements, but they now
behave as iterators into
*this, not into x.
5 Complexity: Constant time.

void splice(const_iterator position, list& x, const_iterator i)
noexcept;
void splice(const_iterator position, list&& x, const_iterator i)
noexcept;
6 Effects: Inserts an element pointed to by i from list x before position and
removes the element from
x. The result is unchanged if position == i or position == ++i. Pointers and
references to *i
continue to refer to this same element but as a member of *this. Iterators to
*i (including i itself)
continue to refer to the same element, but now behave as iterators into *this,
not into x.
[...]
8 Complexity: Constant time.

void splice(const_iterator position, list& x, const_iterator
first,
const_iterator last) noexcept;
void splice(const_iterator position, list&& x, const_iterator
first,
const_iterator last) noexcept;
9 Effects: Inserts elements in the range [first,last) before position and
removes the elements from
x.
[...]
11 Complexity: Constant time if &x == this; otherwise, linear time.
[/quote]

[Bug c/49560] -fexec-charset=IBM-1047 makes -Wformat report incorrect warnings

[jphartmann at gmail dot com]

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

--- Comment #1 from jphartmann at gmail dot com  
2011-06-28 08:25:24 UTC ---
This is how the string shows up in the .s:

[/home/john/src/cmsh/390]  more hlo.s
.file   "hlo.c"
.section.rodata
.LC0:
.string
"\310\226\246\204\250K@@\346\205\210\201\245\205@l\204@\201\231\207\244\224\205\225\243\242%"

The % sign now represents the newline in the ascii string.

The circumvention is to do a dry run with -Wall but without -fexec-charset, so
this is not a priority as far as I am concerned.

[Bug fortran/49562] New: [OOP] ICE at invalid code: assigning value to function of polymorphic object

[boschmann at tp1 dot physik.uni-siegen.de]

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

   Summary: [OOP] ICE at invalid code: assigning value to function
of polymorphic object
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boschm...@tp1.physik.uni-siegen.de
CC: ja...@gcc.gnu.org


The code:

module ice
  type::ice_type
   contains
 procedure::ice_func
  end type ice_type
contains
  pure integer function ice_func(this)
class(ice_type),intent(in)::this
ice_func=1
  end function ice_func
  subroutine ice_sub(a)
class(ice_type)::a
a%ice_func()=1   ! This is the invalid line
  end subroutine ice_sub
end module ice

The marked line is obviously not allowed. When I replace class(ice_type)::a by
type(ice_type)::a then get a proper error message, but the class statement
results in an internal compiler error.

My gfortran version is 4.7.0 20110620

[Bug libstdc++/49559] stable_sort calls self-move-assignment operator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.28 08:41:06
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-06-28 
08:41:06 UTC ---
confirmed, __copy_move_b in stl_algobase.h performs the redundant self-move

this untested change fixes the testcase but I haven't checked if it's correct
or passes the testsuite:

Index: include/bits/stl_algobase.h
===
--- include/bits/stl_algobase.h (revision 175389)
+++ include/bits/stl_algobase.h (working copy)
@@ -541,8 +541,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 static _BI2
 __copy_move_b(_BI1 __first, _BI1 __last, _BI2 __result)
 {
- typename iterator_traits<_BI1>::difference_type __n;
- for (__n = __last - __first; __n > 0; --__n)
+ typename iterator_traits<_BI1>::difference_type __n
+   = __last - __first;
+ if (__n <= 1)
+   return __first;
+ for (; __n > 0; --__n)
*--__result = std::move(*--__last);
  return __result;
}

[Bug libstdc++/49561] gcc does not meet the standard for std::list container

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-06-28 
08:47:47 UTC ---
(In reply to comment #0)
> I realized that the complexity of std::list::size() is O(n), not O(1).
> 
> This does not conform to standard. The standard states that size() function is
> in constant time for alls containers. 

No, the current standard does not.

The C++0x draft does, but it's not yet a standard, and parts of it are not yet
implemented.

[Bug c++/49558] Compiling gcc-3.4.5 source code on MAC OS X 10.6.3 gives an error.

[gcc at microbizz dot nl]

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

Adriaan van Os  changed:

   What|Removed |Added

 CC||gcc at microbizz dot nl

--- Comment #2 from Adriaan van Os  2011-06-28 
08:52:47 UTC ---
(In reply to comment #0)
> While compiling gcc-3.4.5 source code on MAC OS X 10.6.3[which has gcc and cc
> with version i686-apple-darwin10-gcc-4.2.1] gives an error mentioned below.

You will find a patched gcc-3.4.6 gcc/gpc compiler at
 that still compiles on Mac OS X 10.6

[Bug libstdc++/49559] stable_sort calls self-move-assignment operator

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-06-28 
08:56:39 UTC ---
bah, that's testing the wrong thing
the test should be:
  if (__result == __last)
return __first;

[Bug fortran/49540] [4.6/4.7 Regression] Memory-hog with large DATA stmt

[adrian.sevcenco at cern dot ch]

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

Adrian Sevcenco  changed:

   What|Removed |Added

 CC||adrian.sevcenco at cern dot
   ||ch

--- Comment #8 from Adrian Sevcenco  2011-06-28 
08:59:38 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #2)
> > > Thus, in some way, the repeat count must come back. One possibility is to
> > > handle the special case /*/, which is equivalent to
> > > a scalar initialization. I think that should cover the most common case.
> > 
> > IIRC, as implemented the array constructor is completely unrolled, for each
> > element an entry in the splay tree is generated.
> 
> Yes - at least since dropping the repeat count, which your patch did.
> 
> > One could apply the -fmax-array-constructor= restrictions used e.g. 
> > for
> > PARAMETER arrays and do not unroll arrays of size larger than  but 
> > do it
> > on runtime.
> 
> As written, I think it should be sufficient to support the initialization via 
> a
> scalar. In terms of the trans*.c files that already works:
>   real :: a(3) = 0
> thus, there is no reason why one should be able to set sym->value also for
>   real a(3)
>   data a/3*0/
> 
> That is: If - and only if - one has  == size(array), i.e. a
> whole-array initialization, one changes the initialization from:
>   sym->value  =  [ ( , i = 1, ) ]
> to
>   sym->value  =  
> 
> That should require some reshoveling in the code, but sounds much cleaner as
> -fmax-array-constructor= tweaking. Additionally, it will generate much faster
> code for "data a/1000*0.0/" as it gets translated into "static real a =
> {}".

so with regard to the initial submission from 
https://bugzilla.redhat.com/show_bug.cgi?id=716721
(and code from
http://alisoft.cern.ch/viewvc/trunk/TAmpt/AMPT/hijing1.383_ampt.f?view=markup&root=AliRoot)

do you have some specific (and certain) recommendations in order to make this
scientific code to be compiled (alongside with a lot other fortran scientific
code)?
Thanks

[Bug middle-end/49563] New: Expansion forgets to set MEM_VOLATILE_P for TARGET_MEM_REF

[baldrick at gcc dot gnu.org]

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

   Summary: Expansion forgets to set MEM_VOLATILE_P for
TARGET_MEM_REF
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: baldr...@gcc.gnu.org


In expr.c, this code

if (TREE_THIS_VOLATILE (exp))
  MEM_VOLATILE_P (temp) = 1;

sets MEM_VOLATILE_P for a volatile MEM_REF.  But this is not done for a
volatile
TARGET_MEM_REF.  This doesn't matter right now because tree-ssa-loop-ivopts.c
bails out if it sees a volatile memory reference, so volatile TARGET_MEM_REFs
don't (yet) occur in the wild.

[Bug ada/49557] Building the GCC compiler suite fails on a Makefile concerning Ada

[arjen.markus895 at gmail dot com]

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

--- Comment #2 from Arjen Markus  2011-06-28 
09:12:00 UTC ---
Hi Eric,

thanks for looking into this. If I use an absolute path, then the
make command chokes on the lack of a target for "configure" as
required to update "config.status".

Regards,

Arjen

2011/6/28 ebotcazou at gcc dot gnu.org :
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49557
>
> Eric Botcazou  changed:
>
>           What    |Removed                     |Added
> 
>             Status|UNCONFIRMED                 |WAITING
>   Last reconfirmed|                            |2011.06.28 07:27:30
>                 CC|                            |ebotcazou at gcc dot
>                   |                            |gnu.org
>     Ever Confirmed|0                           |1
>
> --- Comment #1 from Eric Botcazou  2011-06-28 
> 07:27:30 UTC ---
> What happens if you use an absolute path to the configure script instead?
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.
>

[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

[iains at gcc dot gnu.org]

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

--- Comment #13 from Iain Sandoe  2011-06-28 09:16:08 
UTC ---
Author: iains
Date: Tue Jun 28 09:16:04 2011
New Revision: 175578

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175578
Log:

PR target/47997
* config/darwin.c (darwin_mergeable_string_section): Place string
constants in '.cstring' rather than '.const' when CF/NSStrings are
active.


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/darwin.c

[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #14 from Iain Sandoe  2011-06-28 09:17:47 
UTC ---
fixed on trunk and 4.6 branch (sorry it took a while to commit the fix).

[Bug middle-end/49563] Expansion forgets to set MEM_VOLATILE_P for TARGET_MEM_REF

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Guenther  2011-06-28 
09:18:30 UTC ---
It looks like set_mem_attributes () will set it via a similar check.

[Bug tree-optimization/49552] missed optimization: test for zero remainder after division by a constant.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.28 09:20:40
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-06-28 
09:20:40 UTC ---
Confirmed.  Is this possible for all constant moduli?

[Bug middle-end/49543] Cast move causes incorrect code and numerical results

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #6 from Richard Guenther  2011-06-28 
09:31:35 UTC ---
There is undefined behavior if the overflow occurs, so the upcast is valid.

[Bug ada/49557] Building the GCC compiler suite fails on a Makefile concerning Ada

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  2011-06-28 
09:32:10 UTC ---
> thanks for looking into this. If I use an absolute path, then the
> make command chokes on the lack of a target for "configure" as
> required to update "config.status".

Huh?  OK, I presume this is the usual mess with paths on Windows.  What version
of make do you use?  Do you use the -j option?

[Bug ada/49557] Building the GCC compiler suite fails on a Makefile concerning Ada

[arjen.markus895 at gmail dot com]

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

--- Comment #4 from Arjen Markus  2011-06-28 
09:40:56 UTC ---
Hi Eric,

I used the path "d://configure", perhaps I should have used
"/d//configure"

I am using the make utility that comes with MinGW/MSYS:
GNU Make 3.81, from 2006.

Hm, could that explain it? A rather old version of make?

Regards,

Arjen

2011/6/28 ebotcazou at gcc dot gnu.org :
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49557
>
> --- Comment #3 from Eric Botcazou  2011-06-28 
> 09:32:10 UTC ---
>> thanks for looking into this. If I use an absolute path, then the
>> make command chokes on the lack of a target for "configure" as
>> required to update "config.status".
>
> Huh?  OK, I presume this is the usual mess with paths on Windows.  What 
> version
> of make do you use?  Do you use the -j option?
>

[Bug middle-end/49545] [4.7 Regression] New C++ test failures

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
2011-06-28 09:42:34 UTC ---
Sorry for the breakage.  I should obviously have tested
on x86_64-linux-gnu as well.

[Bug fortran/49562] [4.6/4.7 Regression] [OOP] ICE at invalid code: assigning value to function of polymorphic object

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.28 09:43:24
Summary|[OOP] ICE at invalid code:  |[4.6/4.7 Regression] [OOP]
   |assigning value to function |ICE at invalid code:
   |of polymorphic object   |assigning value to function
   ||of polymorphic object
 Ever Confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org 2011-06-28 09:43:24 UTC ---
In fact this is a regression: With 4.5 one gets the correct error message.

[Bug libstdc++/49559] stable_sort calls self-move-assignment operator

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jwakely.gcc at gmail dot
   ||com

--- Comment #3 from Paolo Carlini  2011-06-28 
09:45:22 UTC ---
Irrespective of what happens in other functions, I think we want to check at
the beginning of stable_sort whether __last - __first > 1 and thus avoid the
_Temporary_buffer dance otherwise. Then, Jon, I'm not sure to understand what
you propose to do, note that __last and __result have different types. Also
note that the FDIS is *very* explicit about what move_backward does (+ I see
now that we have a typo in the documentation comment: "Result may not be in the
range (first,last]" *not* "Result may not be in the range [first,last)"

[Bug libstdc++/49559] stable_sort calls self-move-assignment operator

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.6.2

[Bug libstdc++/49561] [C++0x] std::list::size complexity

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.28 10:08:36
Summary|gcc does not meet the   |[C++0x] std::list::size
   |standard for std::list  |complexity
   |container   |
 Ever Confirmed|0   |1
   Severity|major   |normal

[Bug bootstrap/49555] libjava fails to configure if --enable-symvers=gnu or --enable-symvers=sun

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC|ro at CeBiTec dot   |ro at gcc dot gnu.org
   |Uni-Bielefeld.DE, ro at |
   |techfak dot |
   |uni-bielefeld.de|
   Target Milestone|--- |4.7.0

--- Comment #2 from Rainer Orth  2011-06-28 10:20:50 UTC 
---
Please provide a bit mor information:

* what platform are you on?

* what are your configure options?

* why do you insist on specifying the symvers flavor manually?

[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||chris at bubblescope dot
   ||net

--- Comment #4 from Paolo Carlini  2011-06-28 
10:41:20 UTC ---
So, I added a:

Index: util/testsuite_rvalref.h
===
--- util/testsuite_rvalref.h(revision 175578)
+++ util/testsuite_rvalref.h(working copy)
@@ -68,6 +68,7 @@
 operator=(rvalstruct&& in)
 {
   bool test __attribute__((unused)) = true;
+  VERIFY( this != &in );
   VERIFY( in.valid == true );
   val = in.val;
   in.valid = false;

and got fails for the 25_algorithms/inplace_merge/moveable.cc tests.

Chris, are you willing to have a look? I seem to remember that you did a lot of
work in this area...

I'm not seeing other fails, luckily.

[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-06-28 
10:45:11 UTC ---
(In reply to comment #3)
> note that the FDIS is *very* explicit about what move_backward does

Ah ok - but if move_backward has to do that then we should avoid calling it at
all when nothing needs to move, maybe in __move_merge_backward

[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  2011-06-28 
10:56:50 UTC ---
Maybe, yes. I'm going to attaching as a draft patch what I have so far, if you
could coordinate with Chris and complete it, would be great...

[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  2011-06-28 
10:58:09 UTC ---
Created attachment 24613
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24613
Draft patch. inplace_merge still needs work.

[Bug c/49560] -fexec-charset=IBM-1047 makes -Wformat report incorrect warnings

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Joseph S. Myers  2011-06-28 
11:03:03 UTC ---
Duplicate.

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

[Bug c/20110] format checking and non-ASCII character sets

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||jphartmann at gmail dot com

--- Comment #2 from Joseph S. Myers  2011-06-28 
11:03:03 UTC ---
*** Bug 49560 has been marked as a duplicate of this bug. ***

[Bug fortran/49562] [4.6/4.7 Regression] [OOP] ICE at invalid code: assigning value to function of polymorphic object

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org 2011-06-28 11:05:08 UTC ---
The fix is pretty trivial:


Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 175562)
+++ gcc/fortran/expr.c(working copy)
@@ -4395,7 +4395,7 @@ gfc_check_vardef_context (gfc_expr* e, bool pointe
 }

   if (!pointer && e->expr_type == EXPR_FUNCTION
-  && sym->result->attr.pointer)
+  && sym->result && sym->result->attr.pointer)
 {
   if (!(gfc_option.allow_std & GFC_STD_F2008))
 {


With this one gets:

a%ice_func()=1   ! This is the invalid line
1
Error: Non-variable expression in variable definition context (assignment) at
(1)

[Bug fortran/49562] [4.6/4.7 Regression] [OOP] ICE at invalid code: assigning value to function of polymorphic object

[janus at gcc dot gnu.org]

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

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-06-28 11:06:29 UTC ---
Also: Mine. [Will commit as obvious after regtesting.]

[Bug fortran/49562] [4.6/4.7 Regression] [OOP] ICE at invalid code: assigning value to function of polymorphic object

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org 2011-06-28 11:18:47 UTC ---
For the record: The regression is probably due to r165749:

http://gcc.gnu.org/viewcvs?view=revision&revision=165749

[Bug middle-end/29274] [4.4/4.5 Regression] not using mulsidi3

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|4.4.7   |4.6.0

[Bug ada/49557] Building the GCC compiler suite fails on a Makefile concerning Ada

[arjen.markus895 at gmail dot com]

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

--- Comment #5 from Arjen Markus  2011-06-28 
11:45:17 UTC ---
When I remove the directories libada and gcc/ada to prevent "make" from
attempting to build Ada, the build process fails on a missing % for a pattern
in gcc/cp/Make-lang.in.

[Bug pch/49435] get_z.c:46: MPFR assertion failed: exp < 0 || exp <= ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))

[longvalery at gmail dot com]

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

--- Comment #6 from Valery  2011-06-28 11:59:52 
UTC ---
Created attachment 24614
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24614
Please. But In ZIP only

[Bug pch/49435] get_z.c:46: MPFR assertion failed: exp < 0 || exp <= ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))

[longvalery at gmail dot com]

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

--- Comment #7 from Valery  2011-06-28 12:03:29 
UTC ---
Created attachment 24615
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24615
I thing that my problem is here

If I comment body of two functions float_16_to_32() and float_24_to_32
compiler work without any error

[Bug pch/49435] get_z.c:46: MPFR assertion failed: exp < 0 || exp <= ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))

[longvalery at gmail dot com]

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

--- Comment #8 from Valery  2011-06-28 12:04:36 
UTC ---
Created attachment 24616
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24616
I thing that my problem is here (2)

If I comment body of function float_32_to_16
compiler work without any error

[Bug target/48273] [4.6 Regression] ICE: in create_copy_of_insn_rtx, at sel-sched-ir.c:5604 with -fsel-sched-pipelining -fselective-scheduling2 -march=core2

[amonakov at gcc dot gnu.org]

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

--- Comment #10 from Alexander Monakov  2011-06-28 
12:19:23 UTC ---
Author: amonakov
Date: Tue Jun 28 12:19:18 2011
New Revision: 175581

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175581
Log:
Backport from mainline
2011-04-08  Alexander Monakov  

PR target/48273
* cfgloop.h (loop_has_exit_edges): New helper.
* sel-sched-ir.c (init_global_and_expr_for_insn): Make CALLs
non-clonable.
* sel-sched.c (sel_setup_region_sched_flags): Don't pipeline loops
that have no exit edges.

* g++.dg/opt/pr48273.C: New.


Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/opt/pr48273.C
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/cfgloop.h
branches/gcc-4_6-branch/gcc/sel-sched-ir.c
branches/gcc-4_6-branch/gcc/sel-sched.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug fortran/49540] [4.6/4.7 Regression] Memory-hog with large DATA stmt

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus  2011-06-28 
12:20:41 UTC ---
(In reply to comment #8)
> do you have some specific (and certain) recommendations in order to make this
> scientific code to be compiled (alongside with a lot other fortran scientific
> code)?

As short term solution: Use an older version of gfortran (before
4.6.0-2010-05-05) - or remove the 0 initialization. While the Fortran standard
does not guarantee it, in practice, static memory should nevertheless be zero
initialized (.bss).

The proper fix will take a bit longer: A couple of days for the fix and then it
will likely also take a while until a Red Hat/Fedora build will be available.
(Though, non-Fedora nightly builds will have it earlier.)

 * * *

(In reply to comment #7)
> As written, I think it should be sufficient to support the initialization
> via a scalar.

For what it is worth: Intel's compiler seem to do the same. Hence,
  DATA B/*/
is is very fast while using
  DATA B(:)/*/
is very slow - even though, both lines are effectively the same.

[Bug target/48273] [4.6 Regression] ICE: in create_copy_of_insn_rtx, at sel-sched-ir.c:5604 with -fsel-sched-pipelining -fselective-scheduling2 -march=core2

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Alexander Monakov  2011-06-28 
12:21:27 UTC ---
Fixed.

[Bug tree-optimization/49552] missed optimization: test for zero remainder after division by a constant.

[wouter.vermaelen at scarlet dot be]

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

--- Comment #2 from Wouter Vermaelen  
2011-06-28 12:22:11 UTC ---
> Confirmed.  Is this possible for all constant moduli?

It is. I recommend you get a copy of the book I mentioned before. The theory
behind the transformation is much better explained there than I could ever do
here. But I'll try to give a recipe to construct the routine for a specific
constant:
(all examples are for 32-bit, but it should be easy enough to generalize)

There are 3 different cases:

(x % C) == 0

* 'x' is unsigned, 'C' is odd:

return (x * Cinv) <= (0x / C);

Where Cinv is the multiplicative inverse of C  (C * Cinv = 1 (modulo pow(2,
32))). Cinv is the same 'magic number' as is used to optimize exact-division
(division where it's known that the remainder will be zero).



* 'x' is unsigned, 'C' is even:

Split 'C' in an odd factor and a power of two.

C = Codd * Ceven
where Ceven = pow(2, k)

Now we test that 'x' is both divisible by 'Codd' and 'Ceven'.

return !(x & (Ceven - 1)) && ((x * Codd_inv) <= (0x / Codd))

When a rotate-right instruction is available, the expression above can be
rewritten so that it only requires one test:

return rotateRight(x * Codd_inv, k) <= (0x / C); // unsigned
comparison



* 'x' is signed, (C can be odd or even)

(I admit, I don't fully understand the theory behind this transformation, so
I'll only give the final result).

constexpr unsigned A = (0x7fff / Codd) & -(1 << k);
constexpr unsigned B = k ? (A >> (k - 1)) : (A << 1);
return rotateRight((x * Codd_inv) + A, k) <= B;   // unsigned comparison

[Bug rtl-optimization/49014] [4.7 Regression] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7132 with even more insane set of flags

[abel at gcc dot gnu.org]

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

--- Comment #6 from Andrey Belevantsev  2011-06-28 
12:46:37 UTC ---
Author: abel
Date: Tue Jun 28 12:46:34 2011
New Revision: 175582

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175582
Log:
Backport from mainline
2011-05-25  Andrey Belevantsev  

PR rtl-optimization/49014
* config/i386/athlon.md (athlon_ssecomi): Change type to ssecomi.


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/i386/athlon.md

[Bug fortran/49562] [4.6/4.7 Regression] [OOP] assigning value to type-bound function

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
Summary|[4.6/4.7 Regression] [OOP]  |[4.6/4.7 Regression] [OOP]
   |ICE-on-invalid: assigning   |assigning value to
   |value to type-bound |type-bound function
   |function|

--- Comment #5 from janus at gcc dot gnu.org 2011-06-28 12:52:58 UTC ---
Note: You can get the same ICE on *valid* code, if you give the return value of
'ice_func' the POINTER attribute (allowed by F08):


module ice
  type::ice_type
   contains
 procedure::ice_func
  end type ice_type
contains
  pure function ice_func(this)
integer, pointer :: ice_func
class(ice_type),intent(in)::this
ice_func=1
  end function ice_func
  subroutine ice_sub(a)
class(ice_type)::a
a%ice_func()=1   ! This is valid now
  end subroutine ice_sub
end module ice


Unfortunately this test case is rejected with the patch in comment #2.

[Bug fortran/49562] [4.6/4.7 Regression] [OOP] assigning value to type-bound function

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org 2011-06-28 12:59:20 UTC ---
(In reply to comment #5)
> Unfortunately this test case is rejected with the patch in comment #2.

However, it is accepted with this improved patch:


Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 175580)
+++ gcc/fortran/expr.c(working copy)
@@ -4394,8 +4394,8 @@ gfc_check_vardef_context (gfc_expr* e, bool pointe
   sym = e->value.function.esym ? e->value.function.esym :
e->symtree->n.sym;
 }

-  if (!pointer && e->expr_type == EXPR_FUNCTION
-  && sym->result->attr.pointer)
+  attr = gfc_expr_attr (e);
+  if (!pointer && e->expr_type == EXPR_FUNCTION && attr.pointer)
 {
   if (!(gfc_option.allow_std & GFC_STD_F2008))
 {
@@ -4432,7 +4432,6 @@ gfc_check_vardef_context (gfc_expr* e, bool pointe

   /* Find out whether the expr is a pointer; this also means following
  component references to the last one.  */
-  attr = gfc_expr_attr (e);
   is_pointer = (attr.pointer || attr.proc_pointer);
   if (pointer && !is_pointer)
 {

[Bug middle-end/49545] [4.7 Regression] New C++ test failures

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #5 from Hans-Peter Nilsson  2011-06-28 
13:07:34 UTC ---
yup, cris-elf (non-strict-alignment) too...

[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  2011-06-28 
13:38:06 UTC ---
For inplace_merge the problem happens with the _GLIBCXX_MOVE3 calls in
__move_merge, at some point __first == __result != __last.

[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #9 from Paolo Carlini  2011-06-28 
14:11:32 UTC ---
Given the specific instantiations we have of __move_merge, something like the
new draft I'm attaching seems correct and avoids the regressions for
inplace_merge. But actually it seems __first2 always == __result after the
first move, thus I think we really want to rework and possibly simplify these
__move_merge helpers.

[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator

[paolo.carlini at oracle dot com]

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

--- Comment #10 from Paolo Carlini  2011-06-28 
14:12:36 UTC ---
Created attachment 24617
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24617
New draft

[Bug c/19541] need another option to support what -I- did just besides -iquote

[jdrosa at yahoo dot com]

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

David Rosa  changed:

   What|Removed |Added

 CC||jdrosa at yahoo dot com

--- Comment #21 from David Rosa  2011-06-28 14:14:37 
UTC ---
I want to add my voice to others who have asked that the priority of this bug
be elevated to P2.

Eliminating the secondary function of -I- as quoted from the GNU preprocessor
documentation is unacceptable.

"Second, the directory containing the current file is not searched for
anything, unless it happens to be one of the directories named by an -I
switch."

Even if a different switch is used, like the -ignore-source-dir I've heard some
rumblings about, can this issue please be elevated in priority and addressed
soon?

For our code base, we utilize gcc along with commercial cross-compilers. All of
the cross-compilers we use support an option that implements the original -I-
behavior and in order to maintain our existing code base, we either -I- to no
longer be deprecated or replaced with a different option that implements the
same behavior.

[Bug c++/49538] Revision 175341 causes segfaults

[markus at trippelsdorf dot de]

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

--- Comment #2 from Markus Trippelsdorf  
2011-06-28 14:49:18 UTC ---
Created attachment 24618
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24618
fix logical thinko

This patch fixes the issue.
It was a simple logical thinko.
It also fixes Bug 49533.

[Bug other/49533] Firefox profiled build issues

[markus at trippelsdorf dot de]

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

--- Comment #4 from Markus Trippelsdorf  
2011-06-28 14:51:15 UTC ---
The patch attached to Bug 49538 fixes this problem.

[Bug target/49564] New: [cppcheck][patch] fixed resource and memory leaks in /gcc/gcc/config/alpha/host-osf.c

[ettl.martin at gmx dot de]

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

   Summary: [cppcheck][patch] fixed resource and memory leaks in
/gcc/gcc/config/alpha/host-osf.c
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ettl.mar...@gmx.de


Created attachment 24619
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24619
proposed patch to fix the issues

cppcheck revealed two resource leaks and a memory leak in
/gcc/gcc/config/alpha/host-osf.c.

Please refer the attached patch that fixed the issues.

Best regards from the cppcheck team

Martin

[Bug fortran/40054] [F08] Pointer functions as lvalue

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org 2011-06-28 15:49:54 UTC ---
cf. also PR 49562

[Bug fortran/49565] New: character(kind=4) is emitted as DW_ATE_unsigned, not DW_ATE_unsigned_char

[tromey at gcc dot gnu.org]

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

   Summary: character(kind=4) is emitted as DW_ATE_unsigned, not
DW_ATE_unsigned_char
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tro...@gcc.gnu.org


I compiled this program with svn trunk gfortran.
I used -gdwarf-4 -g.

character(kind=4) :: c
character(kind=4,len=5) :: str
c = 4_'\u00AE'
str = 4_'\u00AE\u01DD'
open(6,encoding='utf-8')
print *, c
print *, str
end


Then I examined the DWARF.  'c' is ultimately of type:

 <1>: Abbrev Number: 7 (DW_TAG_base_type)
   DW_AT_byte_size   : 4
   DW_AT_encoding: 7(unsigned)
   DW_AT_name: (indirect string, offset: 0x67):
character(kind=4)

I think the encoding should be DW_ATE_unsigned_char instead.

[Bug fortran/49565] character(kind=4) is emitted as DW_ATE_unsigned, not DW_ATE_unsigned_char

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2011-06-28 
16:07:33 UTC ---
>From gcc/dwarf2out.c's base_type_die:

  if (TYPE_STRING_FLAG (type))
{
  if (TYPE_UNSIGNED (type))
encoding = DW_ATE_unsigned_char;

which should set it. However, there is also in gen_array_type_die the following
code:

  /* Emit DW_TAG_string_type for Fortran character types (with kind 1 only, as
 DW_TAG_string_type doesn't have DW_AT_type attribute).  */
  if (TYPE_STRING_FLAG (type)
  && TREE_CODE (type) == ARRAY_TYPE
  && is_fortran ()
  && TYPE_MODE (TREE_TYPE (type)) == TYPE_MODE (char_type_node))

That has been added by Jakub's commit Rev. 139778:
http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=cdba1d8f465a94f6f654bcc33a7663913df2181e;hp=98923a8420e5399f31613d93ebee61e63f2d36e1

Sumitted patch was http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01680.html

[Bug fortran/49566] New: [DWARF/DEBUG] Add coarray shapes (codimensions) to the debug output

[burnus at gcc dot gnu.org]

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

   Summary: [DWARF/DEBUG] Add coarray shapes (codimensions) to the
debug output
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
Blocks: 24546


There is an open extension request for the DWARF to handle "Coshape of Coarrays
in Fortran 2008". This is a tracking bug for gfortran

http://www.dwarfstd.org/ShowIssue.php?issue=090824.1&type=open

(gfortran already supports coarrays.)

[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

  Attachment #24617|0   |1
is obsolete||

--- Comment #11 from Paolo Carlini  2011-06-28 
16:22:05 UTC ---
Comment on attachment 24617
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24617
New draft

Never mind the last patch, isn't ok for stable_sort etc.

[Bug java/49556] The import A cannot be resolved，But the A is placed at the current dir.

[licheng.1212 at gmail dot com]

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

--- Comment #2 from licheng.1212 at gmail dot com  2011-06-28 16:25:21 UTC ---
(In reply to comment #1)
> I think this is correct as classes in the same packages don't cannot be
> imported.

yes,you are right!Please close this bug

[Bug fortran/49565] character(kind=4) is emitted as DW_ATE_unsigned, not DW_ATE_unsigned_char

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2011-06-28 
16:45:35 UTC ---
There are two issues:

 a) The one mentioned by Jakub for the committal cited in comment 1
That seems to be a DWARF bug - and Tromey has now filled an issue; it
should
show up in a while at http://www.dwarfstd.org/Issues.php

The problem is that DW_TAG_string_type does not support DW_AT_type,
which makes it not suitable for character(kind=4) [as it already has to
handle character(kind=1)].

 b) Independent of that issue, GCC should emit DW_ATE_unsigned_char and not
DW_ATE_unsigned


The latter issue seems to come due to the following code in gen_array_type_die:

  if (TYPE_STRING_FLAG (type)
  /* Case handling kind=1 characters. */
{
  ...
  return;
}
  ...
  /* For Fortran multidimensional arrays use DW_ORD_col_major ordering.  */
  if (is_fortran ()
  && TREE_CODE (type) == ARRAY_TYPE
  && TREE_CODE (TREE_TYPE (type)) == ARRAY_TYPE
  && !TYPE_STRING_FLAG (TREE_TYPE (type)))
add_AT_unsigned (array_die, DW_AT_ordering, DW_ORD_col_major);

This test is true as:
  (gdb) p type->type_common.string_flag
  $6 = 1
  (gdb) p type->typed.type->type_common.string_flag
  $7 = 0

I wonder whether the
 && !TYPE_STRING_FLAG (TREE_TYPE (type)))
shouldn't be instead a
 && !TYPE_STRING_FLAG (type))

Or alternatively, whether fortran/trans-type.c's
gfc_get_character_type_len_for_eltype should not only set
  TYPE_STRING_FLAG (type) = 1;
but also
  TYPE_STRING_FLAG (TREE_TYPE (type)) = 1;

[Bug fortran/49565] character(kind=4) is emitted as DW_ATE_unsigned, not DW_ATE_unsigned_char

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2011-06-28 
16:55:16 UTC ---
(In reply to comment #2)
>   /* For Fortran multidimensional arrays use DW_ORD_col_major ordering.  */
>   if (is_fortran ()
>   && TREE_CODE (type) == ARRAY_TYPE
>   && TREE_CODE (TREE_TYPE (type)) == ARRAY_TYPE
>   && !TYPE_STRING_FLAG (TREE_TYPE (type)))
> add_AT_unsigned (array_die, DW_AT_ordering, DW_ORD_col_major);

It's too warm to think poperly: TREE_CODE (type) is ARRAY_TYPE but
TREE_CODE(TREE_TYPE(type)) is INTEGER_TYPE - not an ARRAY_TYPE; hence the code
is never executed. Nevertheless, the issue is presumably related to type having
TYPE_STRING_FLAG set, but TREE_TYPE(type) having it not.

[Bug debug/49567] New: [4.7 Regression] ICE in mem_loc_descriptor due to typed DWARF stack changes

[jakub at gcc dot gnu.org]

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

   Summary: [4.7 Regression] ICE in mem_loc_descriptor due to
typed DWARF stack changes
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


/* { dg-do compile } */
/* { dg-options "-g -O2 -msse4" } */

#include 

__m128
foo (__m128i x)
{
  __m128i y;
  y = _mm_cvtepi16_epi32 (x);
  return _mm_cvtepi32_ps (y);
}

ICEs in mem_loc_descriptor, as we are asserting SIGN_EXTEND/ZERO_EXTEND will
have integral mode, while it has vector mode here.

[Bug debug/49567] [4.7 Regression] ICE in mem_loc_descriptor due to typed DWARF stack changes

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.28 17:01:27
  Known to work||4.6.1
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1
  Known to fail||4.7.0

[Bug debug/49567] [4.7 Regression] ICE in mem_loc_descriptor due to typed DWARF stack changes

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2011-06-28 
17:05:55 UTC ---
Created attachment 24620
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24620
gcc47-pr49567.patch

Untested fix.

[Bug c++/49568] New: [4.7 regression] g++.dg/torture/pr41257-2.C FAILs to link on Tru64 UNIX

[ro at gcc dot gnu.org]

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

   Summary: [4.7 regression] g++.dg/torture/pr41257-2.C FAILs to
link on Tru64 UNIX
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: link-failure
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
  Host: alpha-dec-osf5.1b
Target: alpha-dec-osf5.1b
 Build: alpha-dec-osf5.1b


Between 20110502 and 20110518, g++.dg/torture/pr41257-2.C started to FAIL
on Tru64 UNIX:

A::~A()
typeinfo for A
collect2: error: ld returned 1 exit status

which is a link error (undefined symbols).  This is a regression from the 4.6
branch.  While the input file is identical, the generated code is far longer on
mainline, and contains a call to an undefined function _ZN1AD2Ev (A::~A()).

This may be related to the fact that Tru64 UNIX doesn't support weak
definitions,
but the code is plain wrong.

I'm attaching assembler output from 4.6 and 4.7.

[Bug c++/49568] [4.7 regression] g++.dg/torture/pr41257-2.C FAILs to link on Tru64 UNIX

[ro at gcc dot gnu.org]

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

--- Comment #2 from Rainer Orth  2011-06-28 17:39:00 UTC 
---
Created attachment 24622
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24622
gcc 4.7 assembler output at -O0

[Bug c++/49568] [4.7 regression] g++.dg/torture/pr41257-2.C FAILs to link on Tru64 UNIX

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  2011-06-28 17:38:31 UTC 
---
Created attachment 24621
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24621
gcc 4.6 assembler output at -O0

[Bug bootstrap/49557] make chokes on various Makefile constructs

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|ada |bootstrap
   Host||i686-pc-mingw32
Summary|Building the GCC compiler   |make chokes on various
   |suite fails on a Makefile   |Makefile constructs
   |concerning Ada  |

--- Comment #6 from Eric Botcazou  2011-06-28 
17:42:18 UTC ---
> When I remove the directories libada and gcc/ada to prevent "make" from
> attempting to build Ada, the build process fails on a missing % for a pattern
> in gcc/cp/Make-lang.in.

Needless to say that you aren't expected to run into this kind of problems on a
decent host.  The GNU make version is OK.  You'd probably better reach out to
the MinGW folks and see what they have to say about this.

[Bug ada/49511] [4.6 Regression] acats test setup fails on HP-UX using posix shell

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-06-28 17:58:01 UTC ---
> 505 (hiauly1)dave> /bin/sh
> $ type -p gnatmake 2>/dev/null
> gnatmake is /opt/gnu/gcc/gcc-3.3.4/bin/gnatmake
> $ echo $?
> 0

Drats, sh silently ignores -p.  The following (untested) patch should
cope with this:

diff --git a/gcc/testsuite/ada/acats/run_acats
b/gcc/testsuite/ada/acats/run_acats
--- a/gcc/testsuite/ada/acats/run_acats
+++ b/gcc/testsuite/ada/acats/run_acats
@@ -10,11 +10,11 @@ fi
 # type -p is missing from Solaris 2 /bin/sh and /bin/ksh (ksh88), but both
 # ksh93 and bash have it.
 # type output format differs between ksh88 and ksh93, so avoid it if
-# type -p is present.
+# type -p is present.  Unfortunately, HP-UX 10 /bin/sh ignores -p with type.
 # Fall back to whence which ksh88 and ksh93 provide, but bash does not.

 which () {
-path=`type -p $* 2>/dev/null` && { echo $path; return 0; }
+path=`type -p $* 2>/dev/null | awk '{print $NF}` && { echo $path; return
0; }
 path=`type $* 2>/dev/null | awk '{print $NF}'` && { echo $path; return 0;
}
 path=`whence $* 2>/dev/null` && { echo $path; return 0; }
 return 1

Could you give it a try?

Thanks.
Rainer

[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator

[paolo.carlini at oracle dot com]

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

--- Comment #12 from Paolo Carlini  2011-06-28 
18:06:54 UTC ---
I'm looking at __merge_adaptive and it seems to me that self move assignment
can happen very generically. Consider:

 if (__len1 <= __len2 && __len1 <= __buffer_size)
   {
 _Pointer __buffer_end = _GLIBCXX_MOVE3(__first, __middle, __buffer);
 std::__move_merge(__buffer, __buffer_end, __middle, __last, __first);
   }

here __first comes in memory before __middle and when __move_merge has filled
all the positions before __middle then any element can be move assigned from
itself. Of course we could always move to the buffer the entire range __first,
__last. Still looking for Chris' opinion on this, he updated this code to move
instead of copy...

[Bug bootstrap/49555] libjava fails to configure if --enable-symvers=gnu or --enable-symvers=sun

[bryanhundven at gmail dot com]

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

Bryan Hundven  changed:

   What|Removed |Added

 Target||x86_64-unknown-linux-gnu
   Host||i686-unknown-linux-gnu
  Build||i686-unknown-linux-gnu

--- Comment #3 from Bryan Hundven  2011-06-28 
18:18:33 UTC ---
(In reply to comment #2)
> Please provide a bit mor information:
> 
> * what platform are you on?

It happens on every platform I configure, but if you want something specific:
--build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu

I also have the same problems on:
--build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu
--target=mips64-unknown-linux-gnu

and:
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=powerpc-unknown-linux-gnuspe

This is a build from crosstool-ng. --enable-symvers=gnu is set staticly in:
http://crosstool-ng.org/hg/crosstool-ng/file/tip/scripts/build/cc/gcc.sh

> * what are your configure options?

--enable-languages=c,c++,fortran,objc,obj-c++ --disable-multilib
--with-tune=core2 --with-pkgversion=crosstool-NG hg_unknown@20110627.135200
--disable-sjlj-exceptions --enable-__cxa_atexit --enable-libmudflap
--enable-libgomp --enable-libssp
--with-gmp=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static
--with-mpfr=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static
--with-mpc=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static
--with-ppl=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static
--with-cloog=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static
--with-libelf=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static
--with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++ -lm
-L/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static/lib
-lpwl --enable-threads=posix --enable-target-optspace --disable-libstdcxx-pch
--with-long-double-128 --enable-gold

> * why do you insist on specifying the symvers flavor manually?

"I" didn't insist on specifying it manually. crosstool-ng did.
While you might say that is a problem with crosstool-ng, but the older
crosstool and other cross tool scripts use this as well.

If every other component besides libjava specifically check for
yes|no|gnu*|sun, why doesn't libjava?

Or...

If I shouldn't use --enable-symvers=gnu, shouldn't all other components fail to
support it?

[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option

[gjl at gcc dot gnu.org]

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

--- Comment #17 from Georg-Johann Lay  2011-06-28 
18:26:26 UTC ---
Instead of defining CHAR16_TYPE, I think it's preferred to define
UINT_LEAST16_TYPE appropriately and use logic in defaults.h so that defaults.h
need not to be changed. CHAR16_TYPE is not used in many places, and it appears
that defaults.h is included after tm.h.

UINT_LEAST16_TYPE comes from config/newlib-stdint.h which is merged into avr
headers in config.gcc.

So a fix inside AVR sandbox could be: 

A) Include a new file, say avr/stdint.h, instead of newlib-stdint.h.

or

B) Include newlib-stdint.h prior to avr.h and override as needed.

IMO A) is best because almost anything will have to be overwritten to render
-min8 functional again.

Moreover, note independant of this PR, that newlib-stdint.h makes some
definitions that are not correct for AVR like
   #define SIG_ATOMIC_TYPE "int" // should be "char" for AVR
So it's desired to have AVR-specific stdint.h, anyway.

The major drawback of -mint8 is that it's not covered by the testsuite at all
-- like most other AVR gadgets (ISR, progmem, ...)

If maintainers are willing to support this, I am sure someone will supply
according patch.

Johann

[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option

[gjl at gcc dot gnu.org]

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

--- Comment #18 from Georg-Johann Lay  2011-06-28 
18:34:54 UTC ---
(In reply to comment #17)
> A) Include a new file, say avr/stdint.h, instead of newlib-stdint.h.
> 
> or
> 
> B) Include newlib-stdint.h prior to avr.h and override as needed.

or

C) Omit newlib-stdint.h altogether and to the defines in avr.h.

C) and A) are better than B)

Johann

[Bug ada/49511] [4.6 Regression] acats test setup fails on HP-UX using posix shell

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #4 from dave at hiauly1 dot hia.nrc.ca 2011-06-28 18:46:19 UTC ---
On Tue, 28 Jun 2011, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49511
> 
> --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> 2011-06-28 17:58:01 UTC ---
> > 505 (hiauly1)dave> /bin/sh
> > $ type -p gnatmake 2>/dev/null
> > gnatmake is /opt/gnu/gcc/gcc-3.3.4/bin/gnatmake
> > $ echo $?
> > 0
> 
> Drats, sh silently ignores -p.  The following (untested) patch should
> cope with this:
> 
> Could you give it a try?

The following revised patch works.  There was a missing quote and
the problem also affects HP-UX 11.  I just never hit it since I always
build with bash.

Index: ada/acats/run_acats
===
--- ada/acats/run_acats(revision 175188)
+++ ada/acats/run_acats(working copy)
@@ -10,11 +10,11 @@
 # type -p is missing from Solaris 2 /bin/sh and /bin/ksh (ksh88), but both
 # ksh93 and bash have it.
 # type output format differs between ksh88 and ksh93, so avoid it if
-# type -p is present.
+# type -p is present.  Unfortunately, HP-UX /bin/sh ignores -p with type.
 # Fall back to whence which ksh88 and ksh93 provide, but bash does not.

 which () {
-path=`type -p $* 2>/dev/null` && { echo $path; return 0; }
+path=`type -p $* 2>/dev/null | awk '{print $NF}'` && { echo $path; return
0; }
 path=`type $* 2>/dev/null | awk '{print $NF}'` && { echo $path; return 0;
}
 path=`whence $* 2>/dev/null` && { echo $path; return 0; }
 return 1

Thanks,
Dave

[Bug fortran/49479] [4.6/4.7 Regression] reshape / optionals / zero sized arrays

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  2011-06-28 
18:59:06 UTC ---
Author: tkoenig
Date: Tue Jun 28 18:59:04 2011
New Revision: 175594

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175594
Log:
2011-06-28  Thomas Koenig  

PR fortran/49479
* m4/reshape.m4: If source allocation is smaller than one, set it
to one.
* intrinsics/reshape_generic.c:  Likewise.
* generated/reshape_r16.c: Regenerated.
* generated/reshape_c4.c: Regenerated.
* generated/reshape_c16.c: Regenerated.
* generated/reshape_c8.c: Regenerated.
* generated/reshape_r4.c: Regenerated.
* generated/reshape_i4.c: Regenerated.
* generated/reshape_r10.c: Regenerated.
* generated/reshape_r8.c: Regenerated.
* generated/reshape_c10.c: Regenerated.
* generated/reshape_i8.c: Regenerated.
* generated/reshape_i16.c: Regenerated.

2011-06-28  Thomas Koenig  

PR fortran/49479
* gfortran.dg/reshape_zerosize_3.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/reshape_zerosize_3.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/reshape_c10.c
trunk/libgfortran/generated/reshape_c16.c
trunk/libgfortran/generated/reshape_c4.c
trunk/libgfortran/generated/reshape_c8.c
trunk/libgfortran/generated/reshape_i16.c
trunk/libgfortran/generated/reshape_i4.c
trunk/libgfortran/generated/reshape_i8.c
trunk/libgfortran/generated/reshape_r10.c
trunk/libgfortran/generated/reshape_r16.c
trunk/libgfortran/generated/reshape_r4.c
trunk/libgfortran/generated/reshape_r8.c
trunk/libgfortran/intrinsics/reshape_generic.c
trunk/libgfortran/m4/reshape.m4

[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option

[joseph at codesourcery dot com]

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

--- Comment #19 from joseph at codesourcery dot com  2011-06-28 19:05:00 UTC ---
On Tue, 28 Jun 2011, gjl at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261
> 
> --- Comment #18 from Georg-Johann Lay  2011-06-28 
> 18:34:54 UTC ---
> (In reply to comment #17)
> > A) Include a new file, say avr/stdint.h, instead of newlib-stdint.h.
> > 
> > or
> > 
> > B) Include newlib-stdint.h prior to avr.h and override as needed.
> 
> or
> 
> C) Omit newlib-stdint.h altogether and to the defines in avr.h.
> 
> C) and A) are better than B)

Indeed, I simply made all bare-metal targets use newlib-stdint.h as a 
default, but since AVR has its own libc it seems more appropriate to put 
the defines in avr-stdint.h or avr.h and not use newlib-stdint.h.  (And 
the point of having separate headers such as newlib-stdint.h is that there 
may not otherwise be a header shared between all relevant targets.  If all 
AVR targets use avr-libc, putting the defines in avr.h makes sense, but if 
avr-rtems is using newlib like other RTEMS targets then you probably want 
a separate header only for AVR targets using avr-libc.)

[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator

[chris at bubblescope dot net]

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

--- Comment #13 from Chris Jefferson  2011-06-28 
19:16:00 UTC ---
I am on holiday until tomorrow night, and away from a computer. Once I get
back, I promise to give this my full attention. This code got messy in the
first place because I was trying to make minimal changes to already confusing
code. I still see if this can be easily cleaned, our if we should use a
different method.

[Bug c++/49569] New: -std=gnu++0x causes segmentation fault

[dcb314 at hotmail dot com]

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

   Summary: -std=gnu++0x causes segmentation fault
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


Created attachment 24623
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24623
gzipped C++ source code

I just tried to compile the pokerth-0.8.3-6.fc16  package with the latest
trunk snapshot 20110625 on an AMD x86_64 box.

The compiler said

./include/c++/4.7.0/bits/stl_pair.h:137:45: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

gdb says

Program received signal SIGSEGV, Segmentation fault.
iterative_hash (k_in=, length=,
initval=)
at ../../src/gcc-4.7-20110625/libiberty/hashtab.c:981
981 case 4 : a+=((hashval_t)k[3]<<24);
Missing separate debuginfos, use: debuginfo-install glibc-2.13.90-13.x86_64
gmp-4.3.2-3.fc15.x86_64 mpfr-3.0.0-4.fc15.x86_64
(gdb) p k
$1 = (const unsigned char *) 0x8 

Preprocessed source code attached. Flag -std=gnu++0x required.

[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator

[paolo.carlini at oracle dot com]

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

--- Comment #14 from Paolo Carlini  2011-06-28 
19:38:47 UTC ---
Thanks Chris, I appreciate that, I know I can always count on you. Actually, I
will be on vacation for a few days starting tomorrow, but I will bring the
laptop will be and will be able to provide feedback and all due attention to
your work. I'm thinking, we could also prepare two different fixes: one
minimally invasive for 4.6.2 and another more invasive for 4.7. At the moment,
I'm under the impression that a proper fix involves massaging __merge_adaptive
quite a bit...

[Bug c++/49570] New: /usr/include/c++/4.6.0/bits/stl_algobase.h(378): error: type name is not allowed

[ansayre at babcock dot com]

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

   Summary: /usr/include/c++/4.6.0/bits/stl_algobase.h(378):
error: type name is not allowed
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ansa...@babcock.com


I upgraded v. 4.6.0 from sources on a RHEL 5.5 system. Previously I had v.
4.1.2. I get the following error when using the icc compiler which I did not
have before:

icc -g -O0 -DERR_DEBUG -Wall -wd177,1572 -I. -I/opt/hpmpi/include 
-DDOMAIN_DECOMP_SUPPORTED -DNO_TIMEDATA -DMP_MPI -c ../../src/adapt/tregstr.cpp
/usr/include/c++/4.6.0/bits/stl_algobase.h(378): error: type name is not
allowed
const bool __simple = (__is_trivial(_ValueTypeI)
^
  detected during:
instantiation of "_OI std::__copy_move_a2<_IsMove,_II,_OI>(_II,
_II, _OI) [with _IsMove=false, _II=__gnu_cxx::__normal_iterator>>, _OI=__gnu_cxx::__normal_iterator>>]" at line 454
instantiation of "_OI std::copy(_II, _II, _OI) [with
_II=__gnu_cxx::__normal_iterator>>, _OI=__gnu_cxx::__normal_iterator>>]" at line 139 of
"/usr/include/c++/4.6.0/bits/vector.tcc"
instantiation of
"__gnu_cxx::__normal_iterator::_Tp_alloc_type::pointer, std::vector<_Tp, _Alloc>> std::vector<_Tp,
_Alloc>::erase(__gnu_cxx::__normal_iterator::_Tp_alloc_type::pointer, std::vector<_Tp, _Alloc>>) [with _Tp=Bv *,
_Alloc=std::allocator]" at line 462 of "./bvlist.h"

/usr/include/c++/4.6.0/bits/stl_algobase.h(378): error: identifier
"__is_trivial" is undefined
const bool __simple = (__is_trivial(_ValueTypeI)
   ^
  detected during:
instantiation of "_OI std::__copy_move_a2<_IsMove,_II,_OI>(_II,
_II, _OI) [with _IsMove=false, _II=__gnu_cxx::__normal_iterator>>, _OI=__gnu_cxx::__normal_iterator>>]" at line 454
instantiation of "_OI std::copy(_II, _II, _OI) [with
_II=__gnu_cxx::__normal_iterator>>, _OI=__gnu_cxx::__normal_iterator>>]" at line 139 of
"/usr/include/c++/4.6.0/bits/vector.tcc"
instantiation of
"__gnu_cxx::__normal_iterator::_Tp_alloc_type::pointer, std::vector<_Tp, _Alloc>> std::vector<_Tp,
_Alloc>::erase(__gnu_cxx::__normal_iterator::_Tp_alloc_type::pointer, std::vector<_Tp, _Alloc>>) [with _Tp=Bv *,
_Alloc=std::allocator]" at line 462 of "./bvlist.h"

compilation aborted for ../../src/adapt/tregstr.cpp (code 2)

line 462 of "bvlist.h" is erasing telements from a vector continer "list" :

 this->list.erase(this->list.begin()+i);

[Bug c++/49570] /usr/include/c++/4.6.0/bits/stl_algobase.h(378): error: type name is not allowed

[ansayre at babcock dot com]

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

--- Comment #1 from Alan N. Sayre  2011-06-28 
20:28:52 UTC ---
[ansayre@blgwap02 trunk]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/usr --with-mpc=/usr --with-mpfr=/usr
--wi
th-gmp=/usr --with-ppl=/usr --with-cloog=/usr
Thread model: posix
gcc version 4.6.0 (GCC)
[ansayre@blgwap02 trunk]$

[Bug c++/49570] /usr/include/c++/4.6.0/bits/stl_algobase.h(378): error: type name is not allowed

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Paolo Carlini  2011-06-28 
20:29:23 UTC ---
Report the problem to Intel.

[Bug c++/49538] Revision 175341 causes segfaults

[markus at trippelsdorf dot de]

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

--- Comment #3 from Markus Trippelsdorf  
2011-06-28 20:32:14 UTC ---
Haha, that patch doesn't work. It's identical to:

#if 0
  if (!in_charge_parm_used
  && fns[0]
  && idx == 1
  && !flag_use_repository
  && DECL_INTERFACE_KNOWN (fns[0])
  && (SUPPORTS_ONE_ONLY || !DECL_WEAK (fns[0]))
  && (!DECL_ONE_ONLY (fns[0])
  || (HAVE_COMDAT_GROUP
  && DECL_WEAK (fns[0])))
  && (flag_syntax_only
  /* Set linkage flags appropriately before
 cgraph_create_function_alias looks at them.  */
  && (expand_or_defer_fn_1 (clone)
  || cgraph_same_body_alias (cgraph_get_node (fns[0]),
 clone, fns[0]
{
  alias = true;
  if (DECL_ONE_ONLY (fns[0]))
{
  /* For comdat base and complete cdtors put them
 into the same, *[CD]5* comdat group instead of
 *[CD][12]*.  */
  comdat_group = cdtor_comdat_group (fns[1], fns[0]);
  DECL_COMDAT_GROUP (fns[0]) = comdat_group;
}
}
#endif

So back to square one. But everything points to commit c70f46b057cd12973:

Author: hubicka 
Date:   Sat Jun 11 13:01:53 2011 +

* lto-symtab.c (lto_cgraph_replace_node): Kill same body alias code.
(lto_symtab_resolve_can_prevail_p): Likewise.
...

[Bug c++/49570] /usr/include/c++/4.6.0/bits/stl_algobase.h(378): error: type name is not allowed

[ansayre at babcock dot com]

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

--- Comment #3 from Alan N. Sayre  2011-06-28 
20:35:13 UTC ---
I disagree with your assessment. The C++ header files should not depend on
internal compiler flags. Why is this Intel's problem.

-Original Message-
From: paolo.carlini at oracle dot com [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Tuesday, June 28, 2011 4:30 PM
To: Sayre, Alan N
Subject: [Bug c++/49570] /usr/include/c++/4.6.0/bits/stl_algobase.h(378):
error: type name is not allowed

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Paolo Carlini  2011-06-28
20:29:23 UTC ---
Report the problem to Intel.

[Bug tree-optimization/49539] [4.7 regression] ICE building gnattools

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|ada |tree-optimization

--- Comment #6 from Eric Botcazou  2011-06-28 
20:47:10 UTC ---
Recategorizing.

[Bug c++/49570] /usr/include/c++/4.6.0/bits/stl_algobase.h(378): error: type name is not allowed

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2011-06-28 
20:50:17 UTC ---
The GNU C++ header files depend already on *tons* of non-standard facilities
provided by the GNU C++ front-end, and many more such dependencies are being
added these days. In some cases, eg, std::underlying_type in C++0x, that it's
provably absolutely unavoidable (even not considering quality of implementation
issues). Anyway, normally Intel is pretty good at its GNU compatibility modes,
probably you should only update your Intel compiler too.

[Bug bootstrap/49555] libjava fails to configure if --enable-symvers=gnu or --enable-symvers=sun

[bryanhundven at gmail dot com]

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

Bryan Hundven  changed:

   What|Removed |Added

 CC||yann.morin.1998 at free dot
   ||fr

--- Comment #4 from Bryan Hundven  2011-06-28 
21:01:43 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > Please provide a bit mor information:

Sure. Re-reading comment #3, maybe I sounded a bit brass.
Let me try again.

Yann requested to be CC'd.

> > * what platform are you on?
> 
> It happens on every platform I configure, but if you want something specific:
> --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu
> --target=x86_64-unknown-linux-gnu
> 
> I also have the same problems on:
> --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu
> --target=mips64-unknown-linux-gnu
> 
> and:
> --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
> --target=powerpc-unknown-linux-gnuspe

same response.

> This is a build from crosstool-ng. --enable-symvers=gnu is set staticly in:
> http://crosstool-ng.org/hg/crosstool-ng/file/tip/scripts/build/cc/gcc.sh
> 
> > * what are your configure options?
> 
> --enable-languages=c,c++,fortran,objc,obj-c++ --disable-multilib
> --with-tune=core2 --with-pkgversion=crosstool-NG hg_unknown@20110627.135200
> --disable-sjlj-exceptions --enable-__cxa_atexit --enable-libmudflap
> --enable-libgomp --enable-libssp
> --with-gmp=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static
> --with-mpfr=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static
> --with-mpc=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static
> --with-ppl=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static
> --with-cloog=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static
> --with-libelf=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static
> --with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++ -lm
> -L/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static/lib
> -lpwl --enable-threads=posix --enable-target-optspace --disable-libstdcxx-pch
> --with-long-double-128 --enable-gold

Same response.

> > * why do you insist on specifying the symvers flavor manually?

I had a discussion with Yann E. Morin, and it sounds like this option was
ported forward from the legacy options in Dan Kegel's crosstool.

The questions I am asking should be:

* Should this ever (for any platform) be set manually? Or should this always be
an 'automatic' setting?

* Isn't it inconsistent that every component checks for 'gnu*' and 'sun',
except for libjava?

Yann is currently retesting the sh4 build without --enable-symvers=gnu set to
see if it still needs it. If it does not, then he will remove it completely,
otherwise it should be target specific in crosstool-ng and not for all targets.

> "I" didn't insist on specifying it manually. crosstool-ng did.
> While you might say that is a problem with crosstool-ng, but the older
> crosstool and other cross tool scripts use this as well.
> 
> If every other component besides libjava specifically check for
> yes|no|gnu*|sun, why doesn't libjava?
> 
> Or...
> 
> If I shouldn't use --enable-symvers=gnu, shouldn't all other components fail 
> to
> support it?

[Bug lto/49571] New: -flto -Wl,--as-needed drops needed libraries

[b.r.longbons at gmail dot com]

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

   Summary: -flto -Wl,--as-needed drops needed libraries
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


Created attachment 24624
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24624
Minimal testcase demonstrating the error

Description:
-flto does something funny that makes --as-needed drop more libraries than it
should. See the attached file

Context:
I originally encountered this bug in a big C++ project with -m32, but quickly
reduced it to the attached minimal testcase.
Only in the original project, I got this misleading error:
/usr/bin/ld: /tmp/ccPEhCnW.ltrans4.ltrans.o: undefined reference to symbol
'sqrt@@GLIBC_2.0'
/usr/bin/ld: note: 'sqrt@@GLIBC_2.0' is defined in DSO
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/../../../../../lib32/libm.so
so try adding it to the linker command line
despite -lm *being* explicitly on the command line (which is normally not
needed in C++? Is that standard behavior or is it relying on the indirect
linking thing that *usually* generates that error?)

but this was replaced in the minimal case by the more typical
ccp7SO9X.ltrans0.o:(.text+0x29): undefined reference to `sqrt'


Workaround:
Identify which libraries are *actually* needed and pass them after
-Wl,--no-as-needed.
This works for my particular case (I am building multiple binaries, only one of
which requires -lm) since libm would be loaded indirectly by libstdc++ anyway,
but could be problematic in the general case




System information 1:
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.6.0/work/gcc-4.6.0/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --without-cloog --enable-lto --disable-nls
--with-system-zlib --disable-werror --enable-secureplt --enable-multilib
--enable-libmudflap --disable-libssp --enable-libgomp --enable-cld
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/python
--enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.6.0 p1.2, pie-0.4.5'
Thread model: posix
gcc version 4.6.0 (Gentoo 4.6.0 p1.2, pie-0.4.5) 

System information 2:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.0-13'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 20110611 (prerelease) (Debian 4.6.0-13)

[Bug lto/49571] -flto -Wl,--as-needed drops needed libraries

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-06-28 
23:37:39 UTC ---
I think this only fails when the LTO plugin is enabled.

[Bug regression/49572] New: [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[hp at gcc dot gnu.org]

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

   Summary: [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c
scan-tree-dump-times cddce2 ".rtmem" 0
   Product: gcc
   Version: 4.4.7
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: h...@gcc.gnu.org
CC: ebotca...@gcc.gnu.org
  Host: x86_64-unknown-linux-gnu
Target: cris-axis-elf


This test previously passed, now it fails on the 4.4 branch.
A commit in the revision range 175566:175604, of which the commit at revision
r175603 applies to the 4.4 branch, exposed or caused this regression.
Since then it fails as follows:

...
Running /tmp/hpautotest-gcc44/gcc/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp
...
FAIL: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0
...

The message in gcc.log has no additional information.
The test looks identical to that on trunk, so it doesn't seem to be as trivial
as adjusting it.

Author of suspect patch CC:ed.

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[hp at gcc dot gnu.org]

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

--- Comment #1 from Hans-Peter Nilsson  2011-06-29 
01:30:53 UTC ---
I don't see this regression on the 4.5 branch after the commit.  The autotester
for the 4.6 branch isn't hasn't tested this yet.

[Bug target/49468] SH Target: inefficient integer abs code

[oleg.e...@t-online.de]

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

Oleg Endo  changed:

   What|Removed |Added

  Attachment #24603|0   |1
is obsolete||

--- Comment #6 from Oleg Endo  2011-06-29 01:36:46 UTC 
---
Created attachment 24625
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24625
Proposed patch

Added missing constraints to define_insn_and_split.
Fixed the formatting (hopefully ... there seems to be a problem with the tabs.
I'm using 4 spaces wide tabs)

[Bug rtl-optimization/49573] New: wrong rtl pre transformation

[carrot at google dot com]

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

   Summary: wrong rtl pre transformation
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
  Host: linux
Target: arm-unknown-linux-gnueabi


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

The attached testcase is extracted from skia.

Check out gcc source from gcc4.6 branch earlier than r175024, configured as
arm-unknown-linux-gnueabi and build it. Compile the attached testcase with
options -march=armv7-a -O2 -fno-exceptions, it generates the following code:

_ZN12SkGlyphCache10VisitCacheEPK12SkDescriptor:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfdsp!, {r3, r4, r5, r6, r7, lr}
movr5, r0
ldrr6, .L17
ldrr0, [r6, #0]
bl_Z3fooi
ldrr4, [r6, #4]
cmpr4, #0
beq.L2
.L11:
ldrr1, [r4, #8]
movr2, r5
ldrip, [r1, #4]
movr3, r1
addip, r1, ip
.L4:
ldrr0, [r3], #4
ldrr1, [r2], #4
cmpr0, r1
bne.L3
cmpip, r3
bhi.L4
ldrr3, [r4, #4]
cmpr3, #0
beq.L16   // A
ldrr2, [r4, #0]   
strr2, [r3, #0]
ldrr7, [r4, #0]
.L8:
cmpr7, #0 // B
movr0, r4
ldrner3, [r4, #4]
strner3, [r7, #4]
movr3, #0
strr3, [r4, #0]
strr3, [r4, #4]
ldmfdsp!, {r3, r4, r5, r6, r7, pc}
.L3:
ldrr4, [r4, #0]
cmpr4, #0
bne.L11
.L2:
.L10:
movr0, #12
bl_Znwj
movr4, r0
bl_ZN12SkGlyphCacheC1Ev
movr0, r4
ldmfdsp!, {r3, r4, r5, r6, r7, pc}
.L16:
ldrr3, [r4, #0]  
strr3, [r6, #4]
b.L8
.L18:
.align2
.L17:
.wordgGCGlobals

Note that when the branch instruction A is taken, and later branch to L8,
register r7 will not contain any meaningful value, so instruction B is
unpredictable, and these are incorrect codes.

The culprit is rtl pre pass. Before pre, we have:

...
778 (note 116 107 117 8 [bb 8] NOTE_INSN_BASIC_BLOCK)
779 
780 (insn 117 116 118 8 (set (reg/f:SI 201 [ D.1864 ])
781 (mem/f:SI (reg/v/f:SI 196 [ cache ]) [4 MEM[(struct SkGlyphCache *
*)cache_51]+0 S4 A32])) SkGlyphCache.ii:26 
168 {*arm_movsi_insn}
782  (nil))
783 
784 (insn 118 117 121 8 (set (mem/s/f:SI (reg/f:SI 200 [ D.1863 ]) [4
D.1863_32->fNext+0 S4 A32])
785 (reg/f:SI 201 [ D.1864 ])) SkGlyphCache.ii:26 168 {*arm_movsi_insn}
786  (expr_list:REG_DEAD (reg/f:SI 201 [ D.1864 ])
787 (expr_list:REG_DEAD (reg/f:SI 200 [ D.1863 ])
788 (nil
789 790 (code_label 121 118 122 9 7 "" [1 uses])
791 
792 (note 122 121 123 9 [bb 9] NOTE_INSN_BASIC_BLOCK)
793 
794 (insn 123 122 125 9 (set (reg/f:SI 202 [ D.1864 ])
795 (mem/f:SI (reg/v/f:SI 196 [ cache ]) [4 MEM[(struct SkGlyphCache *
*)cache_51]+0 S4 A32])) SkGlyphCache.ii:28 
168 {*arm_movsi_insn}
796  (nil))
797 
798 (insn 125 123 126 9 (set (reg/f:SI 220)
799 (symbol_ref:SI ("gGCGlobals") [flags 0xc0]  )) SkGlyphCache.ii:28 168 {*ar
m_movsi_insn}
800  (expr_list:REG_EQUAL (symbol_ref:SI ("gGCGlobals") [flags 0xc0] 
)
801 (nil)))
802 
803 (insn 126 125 127 9 (set (mem/s/f/c:SI (plus:SI (reg/f:SI 220)
804 (const_int 4 [0x4])) [4 gGCGlobals.fHead+0 S4 A32])
805 (reg/f:SI 202 [ D.1864 ])) SkGlyphCache.ii:28 168 {*arm_movsi_insn}
806  (expr_list:REG_DEAD (reg/f:SI 220)
807 (expr_list:REG_DEAD (reg/f:SI 202 [ D.1864 ])
808 (nil
809 
810 (code_label 127 126 128 10 8 "" [0 uses])
811 
812 (note 128 127 129 10 [bb 10] NOTE_INSN_BASIC_BLOCK)
813 
814 (insn 129 128 130 10 (set (reg/f:SI 203 [ D.1864 ])
815 (mem/f:SI (reg/v/f:SI 196 [ cache ]) [4 MEM[(struct SkGlyphCache *
*)cache_51]+0 S4 A32])) SkGlyphCache.ii:30 168 {*arm_movsi_insn}
816  (nil))
817 
818 (insn 130 129 131 10 (set (reg:CC 24 cc)
819 (compare:CC (reg/f:SI 203 [ D.1864 ])
820 (const_int 0 [0]))) SkGlyphCache.ii:30 198 {*arm_cmpsi_insn}
821  (nil))
822 
  ...

bb8 and bb9 are predecessors of bb10. insn 129 is fully redundant to insn 117
and 123. But gcc failed to identify this, instead it identified insn 129 is
partial redundant to insn 123. This is still OK. But it did wrong
transformation. It adds a new instruction to load the memory into a new
register r225 at the end of bb8, and modifies the first instruction of bb10 to
move r225 to old register. But it doesn't touch bb9, so if control flows from
bb9 to bb10, the new register r225 contains no meaningful value.

...
286 (note 116 107 117 8 [bb 8] NOTE_INSN_BASIC_BLOCK)
287 
288 (insn 117 116 118 8 (set (

[Bug target/46468] enabling -fomit-frame-pointer by default breaks Wine

[austinenglish at gmail dot com]

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

--- Comment #18 from austinenglish at gmail dot com 2011-06-29 02:16:04 UTC ---
This bug is now affecting the World of Warcraft launcher, which crashes:
http://bugs.winehq.org/show_bug.cgi?id=27057

I've was able to narrow it down to a single .c file in wine (and a single
patch):
http://source.winehq.org/git/wine.git/commitdiff/dc96c688d397eb4ef1392ee6a98f3eb6b176dc56

I'll attach preprocessed files with good/bad gcc.

command used was:
gcc -E -I. -I. -I../../include -I../../include  -D__WINESRC__
-DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing
-Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits
-Wwrite-strings -Wpointer-arith -Wlogical-op  -g -O2  mutation.c &> ~/output.i

good gcc:
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3

bad gcc:
gcc (GCC) 4.6.0 20100812 (experimental)
(this is at commit fc00a76a26bb71539e8e4355e824986baf852f32 / Turn on
-fomit-frame-pointer by default for 32bit Linux/x86.)

[Bug target/46468] enabling -fomit-frame-pointer by default breaks Wine

[austinenglish at gmail dot com]

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

--- Comment #19 from austinenglish at gmail dot com 2011-06-29 02:20:27 UTC ---
Created attachment 24627
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24627
bad preprocessed file

[Bug target/46468] enabling -fomit-frame-pointer by default breaks Wine

[austinenglish at gmail dot com]

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

--- Comment #20 from austinenglish at gmail dot com 2011-06-29 02:20:42 UTC ---
Created attachment 24628
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24628
good preproccessed file

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[hp at gcc dot gnu.org]

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

--- Comment #2 from Hans-Peter Nilsson  2011-06-29 
04:20:26 UTC ---
Nope, not on 4.6 either; it's just 4.4.  Is it possible that the patch was
backported too far?