[Bug fortran/47750] testsuite/gfortran.dg: dg-warning and dg-error should be distinguished

[aldot at gcc dot gnu.org]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot
   ||gnu.org

--- Comment #4 from Bernhard Reutner-Fischer  
2012-03-02 08:01:41 UTC ---
*** Bug 29882 has been marked as a duplicate of this bug. ***

[Bug testsuite/29882] gfortran testsuite doesn't recognize warnings and errors

[aldot at gcc dot gnu.org]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #6 from Bernhard Reutner-Fischer  
2012-03-02 08:01:41 UTC ---
fixed via PR47750

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

[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)

[jakub at gcc dot gnu.org]

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

--- Comment #30 from Jakub Jelinek  2012-03-02 
08:07:15 UTC ---
Created attachment 26809
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26809
pr50182.C

Even the reduced testcase is orders of magnitude longer than what would be
desirable for analysis, I've tried to reduce it just to the templates that are
actually needed (and can be meassured just with time), does this reflect the
slowdowns you are seeing?  The next step at reducing would be to remove all the
template mess, instantiate it by hand, and perhaps also inline by hand.  There
is no reason why we shouldn't be just having one loop with all the statements
in it.  On this reduced testcase on Intel i7-2600 CPU with -O3 the
-DFAST_VER/-DNOINLINE don't seem to make any difference, but 4.6 is measurably
faster than 4.7.

In any case, this is way too late for 4.7.

[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)

[oleg at smolsky dot net]

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

--- Comment #31 from oleg at smolsky dot net 2012-03-02 08:21:41 UTC ---
I don't think there is a need to actually check the result in this 
benchmarkable fragment, so that will reduce the code a little. The only 
thing that I was hitting is about fooling/forcing the compiler not to 
discard the intermediate result and actually perform every calculation 
and iteration :)

Let me try do digest this further. I'll also get you a result from our 
production compiler (v4.1 that emits the fastest code)

[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)

[jakub at gcc dot gnu.org]

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

--- Comment #32 from Jakub Jelinek  2012-03-02 
08:28:34 UTC ---
For me, 4.1 is equally fast to 4.6 on my CPU and on the reduced testcase I've
attached (not clear if it models what the original benchmark did right or not),
and on the trunk regressed with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176072
Before that the inner loop looked like:
.L12:
addl$10, %edx
addb0(%rbp,%rcx), %dl
addq$1, %rcx
cmpl%ecx, %ebx
jg  .L12
and now it looks like:
.L12:
movzbl  0(%rbp,%rdx), %r8d
addq$1, %rdx
cmpl%edx, %ebx
leal10(%rcx,%r8), %ecx
jg  .L12

[Bug c++/52460] New: Misleading error message with templated c++ code

[petschy at gmail dot com]

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

 Bug #: 52460
   Summary: Misleading error message with templated c++ code
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pets...@gmail.com


compiling the following:

---8<---8<---8<---8<---
template
struct Base
{
typename T::Typevar;
};
template
struct Derived : Base >
{
typedef U   Type;
};
void foo()
{
Derived i;
}
---8<---8<---8<---8<---

gives the error

gcctempl.cpp: In instantiation of ‘struct Base >’:
gcctempl.cpp:7:8:   required from ‘struct Derived’
gcctempl.cpp:13:15:   required from here
gcctempl.cpp:4:19: error: no type named ‘Type’ in ‘struct Derived’

on all tested gcc versions (4.4, 4.5, 4.6, 4.7). 

There is definitely a type called 'Type' in struct 'Derived', hence the error
message is misleading.

 I'm not sure, the above code is probably ill-formed, because it creates a
circular dependence between the two types, but then, this should be
communicated to the user.

[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)

[jakub at gcc dot gnu.org]

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

--- Comment #33 from Jakub Jelinek  2012-03-02 
09:13:52 UTC ---
After Jason's patch (which needs to be kept, it was a wrong-code bugfix), we
get out of the FE the addition in int type, while previously it was in unsigned
char type.  I.e.

  int D.2177;
  signed char D.2138;
  T D.2178;
  T D.2179;
  T D.2180;
  signed char result;
D.2138 = custom_constant_add::do_shift (D.2177);
D.2178 = (T) result;
D.2179 = (T) D.2138;
D.2180 = D.2178 + D.2179;
result = (signed char) D.2180;
where T used to be unsigned char before and now is int.
And no GIMPLE optimization pass manages to narrow the addition operation
(together with the previous sign extensions and following demotion) to an
unsigned char operation (signed char would be wrong, because of the possible
overflow).  I bet such narrowing in these cases could even help the vectorizer,
which if it were to vectorize this or similar loops (it doesn't in this case),
would do the promotions/demotions needlessly.

[Bug c++/52460] Misleading error message with templated c++ code

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-02
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2012-03-02 
09:30:46 UTC ---
Clang gives a very similar error but Comeau gives a better one:

"ComeauTest.c", line 4: error: incomplete type is not allowed
  typename T::Typevar;
   ^
  detected during:
instantiation of class "Base [with T=Derived]" at line 7
instantiation of class "Derived [with U=int]" at line 13

[Bug c++/52455] Symbolic constant treated as extern when -O not specified resulting in undefined symbol at link

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-03-02 
09:33:08 UTC ---
This is a FAQ 

http://gcc.gnu.org/wiki/VerboseDiagnostics#undefined_reference_to_.60S::a.27

[Bug c++/52458] [c++0x] compiler fails on for(:*this) with non-public inheritance with message: Internal compiler error: Error reporting routines re-entered.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-02
  Known to work||4.7.0
 Ever Confirmed|0   |1

--- Comment #2 from Jonathan Wakely  2012-03-02 
09:36:09 UTC ---
trunk gives:

l.cc:18:16: error: ‘std::vector’ is not an accessible base of ‘V’

which is better than ICE but still wrong, I think

[Bug tree-optimization/45397] [4.5/4.6/4.7/4.8 Regression] Issues with integer narrowing conversions

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2012-03-02 
09:36:52 UTC ---
Another testcase (lightly based on PR50182), -O3 -mavx:

signed char a[1024], b[1024];

void
foo (void)
{
  int i, s, t;
  for (i = 0; i < 1024; i++)
{ s = a[i]; t = b[i]; s += t; a[i] = s; }
}

void
bar (void)
{
  int i;
  for (i = 0; i < 1024; i++)
a[i] += b[i];
}

shows terrible code for the first loop and nice for the second one, eventhough
both can be implemented as the second loop.

[Bug tree-optimization/45397] [4.5/4.6/4.7/4.8 Regression] Issues with integer narrowing conversions

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2012-03-02 
09:39:16 UTC ---
Note that once can't use signed type in the narrowing + of course, it needs to
be unsigned char addition to avoid overflows.

[Bug tree-optimization/45397] [4.5/4.6/4.7/4.8 Regression] Issues with integer narrowing conversions

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  2012-03-02 
09:48:17 UTC ---
Another testcase:

signed char a[1024], b[1024];

void
baz (void)
{
  int i, s, t;
  for (i = 0; i < 1024; i++)
{ s = a[i]; t = b[i]; s += t + 0x12345600; a[i] = s; }
}

The addition of constant we should be able to optimize away completely, but we
don't.

[Bug tree-optimization/52459] PPRE performs stupid inserts

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-03-02
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
Summary|[x86] loop performance very |PPRE performs stupid
   |bad (worse than -O0) when   |inserts
   |using sse4.2 popcnt |
 Ever Confirmed|0   |1
  Known to fail||4.7.0

--- Comment #3 from Richard Guenther  2012-03-02 
10:00:38 UTC ---
I will have a look.

[Bug target/52457] Wrong VSX code generation bug when compiled with -O1 -m32 -mcpu=power7

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-02
 Ever Confirmed|0   |1

[Bug target/49069] [4.6/4.7 Regression] ICE in gen_cstoredi4, at config/arm/arm.md:7554

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Component|tree-optimization   |target
   Target Milestone|--- |4.6.4

--- Comment #8 from Richard Guenther  2012-03-02 
10:06:17 UTC ---
I don't think what the tree level does is wrong.  Target patch suggests target
bug.

[Bug c++/52458] [c++0x] compiler fails on for(:*this) with non-public inheritance with message: Internal compiler error: Error reporting routines re-entered.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||4.6.2

--- Comment #3 from Jonathan Wakely  2012-03-02 
10:34:56 UTC ---
(In reply to comment #2)
> trunk gives:
> 
> l.cc:18:16: error: ‘std::vector’ is not an accessible base of ‘V’
> 
> which is better than ICE but still wrong, I think

Oops, I was distracted by the range-for loop. That error is for the call to
a.resize() which is of course invalid.

But this valid code still gets an ICE from 4.6

#include 

class V : protected std::vector
{
public:
  void echo()
  {
  for (int x:*this) { }
  }
};


int main()
{
V a;
a.echo();
}

[Bug fortran/52452] [4.5/4.6/4.7 Regression] INTRINSIC cannot be applied to gfortran's ETIME

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2012-03-02 
11:00:17 UTC ---
Author: burnus
Date: Fri Mar  2 11:00:04 2012
New Revision: 184778

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184778
Log:
2012-03-02  Tobias Burnus  

PR fortran/52452
* resolve.c (resolve_intrinsic): Don't search for a
function if we know that it is a subroutine.

2012-03-02  Tobias Burnus  

PR fortran/52452
* gfortran.dg/intrinsic_8.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/intrinsic_8.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk

[evrinoma at gmail dot com]

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

--- Comment #11 from evrinoma at gmail dot com 2012-03-02 11:13:22 UTC ---
many thanks for help 

the asterisk makefile detecting and using incorrect compilation flags

ifeq ($(OSARCH),linux-gnu)
  ifeq ($(PROC),x86_64)
# You must have GCC 3.4 to use k8, otherwise use athlon
#PROC=k8
PROC=nocona
#PROC=athlon
  endif

i changed parameter PROC on nocona 
The program successful build and program successful start without any errors

[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #12 from Jonathan Wakely  2012-03-02 
11:17:59 UTC ---
not a gcc bug then

[Bug fortran/48820] TR 29113: Implement parts needed for MPI 3

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #9 from Tobias Burnus  2012-03-02 
11:30:59 UTC ---
(In reply to comment #8)
> > Patch for TYPE(*)
> 
> Just a warning to testers: [...]

Actually, the argument passing issue was a test-case bug. However, SHAPE and
SIZE (w/o dim=) where indeed mishandled. That's now fixed.

Patch, submitted for GCC 4.8:
  http://gcc.gnu.org/ml/fortran/2012-03/msg4.html

[Bug target/52461] New: [avr] XMEGA+EBI: RAMPZ clobbered while reading from flash

[gjl at gcc dot gnu.org]

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

 Bug #: 52461
   Summary: [avr] XMEGA+EBI: RAMPZ clobbered while reading from
flash
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
Target: avr


To read from flash on devices with more than 64KiB of flash, RAMPZ is set
appropriately before using ELPM instruction.

Devices with external bus interface (EBI) use RAMPZ as high part of the RAM
address while reading from RAM.

Thus, and RAM read on EBI device that is performed via Z will fail after data
has been read from Flash.

[Bug target/52461] [avr] XMEGA+EBI: RAMPZ clobbered while reading from flash

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||eric.weddington at atmel
   ||dot com
   Target Milestone|--- |4.7.1

--- Comment #1 from Georg-Johann Lay  2012-03-02 
12:22:56 UTC ---
Eric, would you confirm this is actually a problem and set bug status to NEW?
Or set to INVALID if I misunderstood the EBI.

Can the EBI be switched off, so that RAMPZ affects ELPM but not LD?

[Bug target/52461] [avr] XMEGA+EBI: RAMPZ clobbered while reading from flash

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||fbi.sr at gmx dot de
   Target Milestone|4.7.1   |4.7.0

[Bug c++/52458] [c++0x] compiler fails on for(:*this) with non-public inheritance with message: Internal compiler error: Error reporting routines re-entered.

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-03-02 
12:39:03 UTC ---
It works ok if you do the conversion to the base class explicitly:

  for (int x: static_cast&>(*this)) { }

I think the range-for code needs to do overload resolution in the class' scope,
but it fails to and tries to say the begin/end members are protected, then gets
into trouble while trying to print the error message.

[Bug fortran/52270] [OOP] Polymorphic vars: wrong intent(in) check, passing nonptr variable to intent(in) ptr dummy

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2012-03-02 
13:07:55 UTC ---
Author: burnus
Date: Fri Mar  2 13:07:46 2012
New Revision: 184784

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184784
Log:
2012-03-02  Tobias Burnus  

PR fortran/52270
* expr.c (gfc_check_vardef_context): Fix check for
intent-in polymorphic pointer .
* interface.c (compare_parameter): Allow passing TYPE to
intent-in polymorphic pointer.

2012-03-02  Tobias Burnus  

PR fortran/52270
* gfortran.dg/class_51.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/class_51.f90
trunk/gcc/testsuite/gfortran.dg/class_52.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/52325] unclear error: Unclassifiable statement

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2012-03-02 
13:21:00 UTC ---
Author: burnus
Date: Fri Mar  2 13:20:52 2012
New Revision: 184785

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184785
Log:
2012-03-02  Tobias Burnus  

PR fortran/52325
* primary.c (gfc_match_varspec): Add diagnostic for % with
nonderived types.

2012-03-02  Tobias Burnus  

PR fortran/52325
* gfortran.dg/derived_comp_array_ref_8.f90: New.
* gfortran.dg/nullify_2.f90: Update dg-error.
* gfortran.dg/nullify_4.f90: Ditto.
* gfortran.dg/pointer_init_6.f90: Ditto.


Added:
trunk/gcc/testsuite/gfortran.dg/derived_comp_array_ref_8.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/nullify_2.f90
trunk/gcc/testsuite/gfortran.dg/nullify_4.f90
trunk/gcc/testsuite/gfortran.dg/pointer_init_6.f90

[Bug fortran/52270] [OOP] Polymorphic vars: wrong intent(in) check, passing nonptr variable to intent(in) ptr dummy

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from Tobias Burnus  2012-03-02 
13:35:13 UTC ---
FIXED on the trunk (i.e. GCC 4.8).

[Bug fortran/52325] unclear error: Unclassifiable statement

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #6 from Tobias Burnus  2012-03-02 
13:36:35 UTC ---
FIXED on the trunk (i.e. GCC 4.8).

It had bothered me already a couple of times - your PR report finally nudged me
to fix it.

Thanks for the bug report.

[Bug fortran/52325] unclear error: Unclassifiable statement

[kloedej at knmi dot nl]

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

--- Comment #7 from Jos de Kloe  2012-03-02 13:50:59 
UTC ---
Thanks for your (really) fast response and fix.
I'll keep my eye open for other details that might improve gfortran.

[Bug go/52462] New: Several libgo tests FAIL intermittently: ../testdata races

[ro at gcc dot gnu.org]

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

 Bug #: 52462
   Summary: Several libgo tests FAIL intermittently: ../testdata
races
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
AssignedTo: i...@airs.com
ReportedBy: r...@gcc.gnu.org


I've seen several libgo testcases FAIL intermittently during highly parallel
bootstraps.  One example is

ln: creating symbolic link `../testdata/testdata': File exists
--- FAIL: flate.TestDeflateInflateString (0.24 seconds)
???:1: open ../testdata/e.txt: No such file or directory
???:1: open ../testdata/Mark.Twain-Tom.Sawyer.txt: No such file or
directory
FAIL
FAIL: compress/flate

I think I understand now what's going on: in testsuite/gotest, we have:

# Some tests refer to a ../testdata directory.
if test -e $srcdir/../testdata; then
  rm -f ../testdata
  abssrcdir=`cd $srcdir && pwd`
  ln -s $abssrcdir/../testdata ../testdata
fi

This construct is racy and inherently unreliable: if between the rm and ln -s
another gotest instance manages to create the ../testdata symlink, the ln -s
here will create its link inside the linked-to testdata directory in $srcdir,
writing into $srcdir which is not supposed to happen.  I've got instances of
this:

> pwd
/vol/gcc/src/hg/trunk/local/libgo/go
> ll -d */testdata/testdata
lrwxrwxrwx 1 ro gcc 62 Feb 24 18:42 compress/testdata/testdata ->
/vol/gcc/src/hg/trunk/local/libgo/go/compress/gzip/../testdata/
lrwxrwxrwx 1 ro gcc 62 Feb 24 20:58 html/testdata/testdata ->
/vol/gcc/src/hg/trunk/local/libgo/go/net/http/fcgi/../testdata/
lrwxrwxrwx 1 ro gcc 60 Feb 24 18:42 image/testdata/testdata ->
/vol/gcc/src/hg/trunk/local/libgo/go/image/color/../testdata/

Even if one replaced the rm/ln -s by a single ln -sf (no idea how portable 
that is), if between the creation of the link and its use another gotest
instance recreates it, pointing to a different directory, the failures occur
just the same.

This can only be avoided by not sharing ../testdata between different gotest
runs.  I see several possibilities:

* Replace ../testdata by testdata in the testcases.  I've no idea how this
  affects upstream libgo.

* Create an intermediate subdir in gotest$$.

* Use different directory names for testdata to avoid conflicts.

  Rainer

[Bug target/52425] [4.6 Regression] ICE when compiling file from audacious on debian sparc

[bernds at gcc dot gnu.org]

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

--- Comment #4 from Bernd Schmidt  2012-03-02 
14:22:54 UTC ---
For some reason I can never reproduce sparc bugs with cross compilers. The
original testcase doesn't fail here; the reduced one fails but with a different
error message, and it fails in instantiate_virtual_regs which is before any
head-merging ever runs:

sparcbug.i: In function ‘action_button_cb’:
sparcbug.i:57:1: error: unrecognizable insn:
(insn 7 6 8 3 (set (reg:SI 130)
(lo_sum:SI (reg:SI 130)
(unspec:SI [
(symbol_ref/f:DI ("*.LC0") [flags 0x2] )
] 0))) sparcbug.i:49 -1
 (nil))

Breakpoint 2, internal_error (gmsgid=0xd6093d "in %s, at %s:%d") at
../../trunk/gcc/diagnostic.c:839
839{
(gdb) bt
#0  internal_error (gmsgid=0xd6093d "in %s, at %s:%d") at
../../trunk/gcc/diagnostic.c:839
#1  0x00bcf7cc in fancy_abort (file=, line=2123,
function=0xc99260 "extract_insn")
at ../../trunk/gcc/diagnostic.c:899
#2  0x0081e8d3 in _fatal_insn (msgid=,
insn=0x76bc5990, 
file=0xc9885b "../../trunk/gcc/recog.c", line=2123, function=0xc99260
"extract_insn")
at ../../trunk/gcc/rtl-error.c:110
#3  0x0081e912 in _fatal_insn_not_found (insn=0xc99260, file=0xc9886b
"recog.c", line=2123, 
function=0xa ) at
../../trunk/gcc/rtl-error.c:118
#4  0x007ea2b4 in extract_insn (insn=0x76bc5990) at
../../trunk/gcc/recog.c:2123
#5  0x006cfe1c in instantiate_virtual_regs_in_insn
(insn=0x76bc5990) at ../../trunk/gcc/function.c:1555
#6  instantiate_virtual_regs () at ../../trunk/gcc/function.c:1911

Please post the actual command line that gets passed to cc1. Also, it would be
helpful if you could load cc1 into a debugger and do the following at the crash
site in output_addr_const:

(gdb) p debug_rtx (x)

and at some higher level, also use debug_rtx to print out the insn it's trying
to print.

[Bug target/46716] [4.4/4.5/4.6/4.7 Regression] wrong code generated with -mno-sse2 -m64

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

Summary|[4.4/4.5/4.6/4.7/4.8|[4.4/4.5/4.6/4.7
   |Regression] wrong code  |Regression] wrong code
   |generated with -mno-sse2|generated with -mno-sse2
   |-m64|-m64

--- Comment #8 from Uros Bizjak  2012-03-02 14:35:24 
UTC ---
This is just a matter of always forcing the "natural" mode for the register,
even when type system does not agree with this. See the comment for
gen_reg_or_parallel on this issue.

I am testing following patch:

Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 184774)
+++ config/i386/i386.c  (working copy)
@@ -6338,15 +6338,16 @@ construct_container (enum machine_mode mode, enum
   }
   if (n == 2 && regclass[0] == X86_64_SSE_CLASS
   && regclass[1] == X86_64_SSEUP_CLASS && mode != BLKmode)
-return gen_rtx_REG (mode, SSE_REGNO (sse_regno));
+return gen_reg_or_parallel (mode, orig_mode,
+   SSE_REGNO (sse_regno));
   if (n == 4
   && regclass[0] == X86_64_SSE_CLASS
   && regclass[1] == X86_64_SSEUP_CLASS
   && regclass[2] == X86_64_SSEUP_CLASS
   && regclass[3] == X86_64_SSEUP_CLASS
   && mode != BLKmode)
-return gen_rtx_REG (mode, SSE_REGNO (sse_regno));
-
+return gen_reg_or_parallel (mode, orig_mode,
+   SSE_REGNO (sse_regno));
   if (n == 2
   && regclass[0] == X86_64_X87_CLASS && regclass[1] == X86_64_X87UP_CLASS)
 return gen_rtx_REG (XFmode, FIRST_STACK_REG);

[Bug c++/52458] [c++0x] compiler fails on for(:*this) with non-public inheritance with message: Internal compiler error: Error reporting routines re-entered.

[crimaniak at gmail dot com]

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

--- Comment #5 from Alexey Kulentsov  2012-03-02 
14:49:41 UTC ---
(In reply to comment #4)

>It works ok if you do the conversion to the base class explicitly:
 Yes, I just make public inheritance so this problem is non-blocking for me,
but this was a bug so I post it. It's pity MinGW updated only to 4.6.2.

> I think the range-for code needs to do overload resolution in the class' 
> scope,
> but it fails to and tries to say the begin/end members are protected, then 
> gets
> into trouble while trying to print the error message.

Agree. Diagnostics problem.

[Bug tree-optimization/50031] Sphinx3 has a 10% regression going from GCC 4.5 to GCC 4.6 on powerpc

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from William J. Schmidt  2012-03-02 
14:52:09 UTC ---
Author: wschmidt
Date: Fri Mar  2 14:51:58 2012
New Revision: 184787

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184787
Log:
2012-03-02  Bill Schmidt 
Ira Rosen 

PR tree-optimization/50031
PR tree-optimization/50969
* targhooks.c (default_builtin_vectorization_cost): Handle
vec_promote_demote.
* target.h (enum vect_cost_for_stmt): Add vec_promote_demote.
* tree-vect-loop.c (vect_get_single_scalar_iteraion_cost): Handle
all types of reduction and pattern statements.
(vect_estimate_min_profitable_iters): Likewise.
* tree-vect-stmts.c (vect_model_promotion_demotion_cost): New function.
(vect_model_store_cost): Use vec_perm rather than vector_stmt for
statement cost.
(vect_model_load_cost): Likewise.
(vect_get_load_cost): Likewise; add dump logic for explicit realigns.
(vectorizable_type_demotion): Call vect_model_promotion_demotion_cost.
(vectorizable_type_promotion): Likewise.
* config/spu/spu.c (spu_builtin_vectorization_cost): Handle
vec_promote_demote.
* config/i386/i386.c (ix86_builtin_vectorization_cost): Likewise.
* config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Update
vec_perm for VSX and handle vec_promote_demote.


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/i386/i386.c
branches/gcc-4_6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_6-branch/gcc/config/spu/spu.c
branches/gcc-4_6-branch/gcc/target.h
branches/gcc-4_6-branch/gcc/targhooks.c
branches/gcc-4_6-branch/gcc/tree-vect-loop.c
branches/gcc-4_6-branch/gcc/tree-vect-stmts.c

[Bug tree-optimization/50969] 17% degradation in 168.wupwise for interleave via permutation

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from William J. Schmidt  2012-03-02 
14:52:09 UTC ---
Author: wschmidt
Date: Fri Mar  2 14:51:58 2012
New Revision: 184787

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184787
Log:
2012-03-02  Bill Schmidt 
Ira Rosen 

PR tree-optimization/50031
PR tree-optimization/50969
* targhooks.c (default_builtin_vectorization_cost): Handle
vec_promote_demote.
* target.h (enum vect_cost_for_stmt): Add vec_promote_demote.
* tree-vect-loop.c (vect_get_single_scalar_iteraion_cost): Handle
all types of reduction and pattern statements.
(vect_estimate_min_profitable_iters): Likewise.
* tree-vect-stmts.c (vect_model_promotion_demotion_cost): New function.
(vect_model_store_cost): Use vec_perm rather than vector_stmt for
statement cost.
(vect_model_load_cost): Likewise.
(vect_get_load_cost): Likewise; add dump logic for explicit realigns.
(vectorizable_type_demotion): Call vect_model_promotion_demotion_cost.
(vectorizable_type_promotion): Likewise.
* config/spu/spu.c (spu_builtin_vectorization_cost): Handle
vec_promote_demote.
* config/i386/i386.c (ix86_builtin_vectorization_cost): Likewise.
* config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Update
vec_perm for VSX and handle vec_promote_demote.


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/i386/i386.c
branches/gcc-4_6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_6-branch/gcc/config/spu/spu.c
branches/gcc-4_6-branch/gcc/target.h
branches/gcc-4_6-branch/gcc/targhooks.c
branches/gcc-4_6-branch/gcc/tree-vect-loop.c
branches/gcc-4_6-branch/gcc/tree-vect-stmts.c

[Bug tree-optimization/52406] [4.7/4.8 Regression] likely wrong code bug

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2012-03-02 
14:59:01 UTC ---
Author: rguenth
Date: Fri Mar  2 14:58:55 2012
New Revision: 184789

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184789
Log:
2012-03-02  Richard Guenther  

PR tree-optimization/52406
* tree-data-ref.h: Update documentation about DR_BASE_OBJECT.
(struct indices): Add unconstrained_base member.
(struct dr_alias): Remove unused vops member.
(DR_UNCONSTRAINED_BASE): New define.
* tree-data-ref.c (dr_analyze_indices): For COMPONENT_REFs
add indices to allow their disambiguation.  Make DR_BASE_OBJECT
be an artificial access that covers the whole indexed object,
or mark it with DR_UNCONSTRAINED_BASE if we cannot do so.  Canonicalize
plain decl base-objects to their MEM_REF variant.
(dr_may_alias_p): When the base-object of either data reference
has unknown size use only points-to information.
(compute_affine_dependence): Make dumps easier to read and
more verbose.
* tree-vect-data-ref.c (vector_alignment_reachable_p): Use
DR_REF when looking for packed references.
(vect_supportable_dr_alignment): Likewise.

* gcc.dg/torture/pr52406.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr52406.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c
trunk/gcc/tree-data-ref.h
trunk/gcc/tree-vect-data-refs.c

[Bug fortran/52325] unclear error: Unclassifiable statement

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  2012-03-02 
14:59:05 UTC ---
Author: burnus
Date: Fri Mar  2 14:58:58 2012
New Revision: 184790

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184790
Log:
2012-03-02  Tobias Burnus  

PR fortran/52325
* primary.c (gfc_match_varspec): Add missing ;.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c

[Bug fortran/52452] [4.5/4.6/4.7/4.8 Regression] INTRINSIC cannot be applied to gfortran's ETIME

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2012-03-02 
15:03:22 UTC ---
(In reply to comment #2)
> New Revision: 184778
> Modified:
> trunk/gcc/fortran/resolve.c


As it is far from being obvious what "trunk" means: At that point "trunk" was
already GCC 4.8.

Thus, the patch needs to be backported to 4.5, 4.6, and to 4.7.

[Bug tree-optimization/50031] Sphinx3 has a 10% regression going from GCC 4.5 to GCC 4.6 on powerpc

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #8 from William J. Schmidt  2012-03-02 
15:02:23 UTC ---
I'm going to mark this fixed at this point, but there are still a couple of
future work items arising from the original issue that should be considered:

1) Loop versioning for alignment.

2) Better cost modeling (on powerpc64, at least) for pipeline limitations on
vector permute and certain other instructions.

[Bug tree-optimization/52406] [4.7 Regression] likely wrong code bug

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Known to work||4.8.0
Summary|[4.7/4.8 Regression] likely |[4.7 Regression] likely
   |wrong code bug  |wrong code bug

--- Comment #9 from Richard Guenther  2012-03-02 
15:04:56 UTC ---
Fixed on trunk sofar.

[Bug testsuite/16464] gfortran.dg test harness does not use loop

[aldot at gcc dot gnu.org]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2012-03/msg00121.htm
   ||l
 CC||aldot at gcc dot gnu.org
 Resolution||WONTFIX

--- Comment #1 from Bernhard Reutner-Fischer  
2012-03-02 15:53:35 UTC ---
Closing as WONTFIX as per Richi.

[Bug target/52457] Wrong VSX code generation bug when compiled with -O1 -m32 -mcpu=power7

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2012-03/msg00132.htm
   ||l

--- Comment #2 from Peter Bergner  2012-03-02 
15:59:27 UTC ---
Patch posted to gcc-patches in the URL above.

[Bug c++/51989] std::deque::iterator recognised as container

[paolo at gcc dot gnu.org]

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

--- Comment #11 from paolo at gcc dot gnu.org  
2012-03-02 16:18:34 UTC ---
Author: paolo
Date: Fri Mar  2 16:18:25 2012
New Revision: 184796

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184796
Log:
/cp
2012-03-02  Paolo Carlini  

PR c++/51989
* typeck2.c (build_x_arrow): Take a tsubst_flags_t argument and
propagate it.
* cp-tree.h (build_x_arrow): Adjust prototype.
* pt.c (tsubst_copy_and_build): Adjust call.
* parser.c (cp_parser_postfix_dot_deref_expression): Likewise.

/testsuite
2012-03-02  Paolo Carlini  

PR c++/51989
* g++.dg/cpp0x/sfinae32.C: New.


Added:
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae32.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

[Bug target/52425] [4.6 Regression] ICE when compiling file from audacious on debian sparc

[mikpe at it dot uu.se]

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

--- Comment #5 from Mikael Pettersson  2012-03-02 
16:21:37 UTC ---
Reproduced with a vanilla gcc-4.6-20120224, configured
/tmp/gcc-4.6-20120224/configure --target=sparc64-unknown-linux
--prefix=/home/mikpe/pkgs/linux-x86/cross-sparc64
--with-gmp=/home/mikpe/pkgs/linux-x86/gmp-5.0.4
--with-mpfr=/home/mikpe/pkgs/linux-x86/mpfr-3.1.0
--with-mpc=/home/mikpe/pkgs/linux-x86/mpc-0.9 --disable-libquadmath
--disable-plugin --disable-lto --disable-nls --disable-shared
--disable-libmudflap --disable-libgomp --disable-multilib
--enable-threads=posix --enable-checking=release --enable-languages=c, and
running on i686-linux.

Original test case:
> /tmp/objdir/gcc/xgcc -B/tmp/objdir/gcc -fPIC -g -O2 -std=gnu99 -pthread -S 
> -m32 -mcpu=v8 pr52425-1.i
ui_fileopener.c:200:1: internal compiler error: output_operand: invalid
expression as operand

Reduced test case (with -v for completeness):
> /tmp/objdir/gcc/xgcc -B/tmp/objdir/gcc -v -fPIC -g -O2 -std=gnu99 -pthread -S 
> -m32 -mcpu=v8 pr52425-2.c
Reading specs from /tmp/objdir/gcc/specs
COLLECT_GCC=/tmp/objdir/gcc/xgcc
COLLECT_LTO_WRAPPER=/tmp/objdir/gcc/lto-wrapper
Target: sparc64-unknown-linux
Configured with: /tmp/gcc-4.6-20120224/configure --target=sparc64-unknown-linux
--prefix=/home/mikpe/pkgs/linux-x86/cross-sparc64
--with-gmp=/home/mikpe/pkgs/linux-x86/gmp-5.0.4
--with-mpfr=/home/mikpe/pkgs/linux-x86/mpfr-3.1.0
--with-mpc=/home/mikpe/pkgs/linux-x86/mpc-0.9 --disable-libquadmath
--disable-plugin --disable-lto --disable-nls --disable-shared
--disable-libmudflap --disable-libgomp --disable-multilib
--enable-threads=posix --enable-checking=release --enable-languages=c
Thread model: posix
gcc version 4.6.3 20120224 (prerelease) (GCC) 
COLLECT_GCC_OPTIONS='-B' '/tmp/objdir/gcc' '-v' '-fPIC' '-g' '-O2' '-std=gnu99'
'-pthread' '-S' '-m32' '-mcpu=v8'
 /tmp/objdir/gcc/cc1 -quiet -v -imultilib . -iprefix
/tmp/objdir/gcc/../lib/gcc/sparc64-unknown-linux/4.6.3/ -isystem
/tmp/objdir/gcc/include -isystem /tmp/objdir/gcc/include-fixed -D__sparc_v8__
-D_REENTRANT pr52425-2.c -mptr32 -mno-stack-bias -mlong-double-64 -quiet
-dumpbase pr52425-2.c -m32 -mcpu=v8 -auxbase pr52425-2 -g -O2 -std=gnu99
-version -fPIC -o pr52425-2.s
GNU C (GCC) version 4.6.3 20120224 (prerelease) (sparc64-unknown-linux)
compiled by GNU C version 4.5.4 20120223 (prerelease), GMP version
5.0.4, MPFR version 3.1.0-p4, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/tmp/objdir/gcc/../lib/gcc/sparc64-unknown-linux/4.6.3/include"
ignoring nonexistent directory
"/tmp/objdir/gcc/../lib/gcc/sparc64-unknown-linux/4.6.3/include-fixed"
ignoring nonexistent directory
"/tmp/objdir/gcc/../lib/gcc/sparc64-unknown-linux/4.6.3/../../../../sparc64-unknown-linux/sys-include"
ignoring nonexistent directory
"/tmp/objdir/gcc/../lib/gcc/sparc64-unknown-linux/4.6.3/../../../../sparc64-unknown-linux/include"
ignoring nonexistent directory
"/tmp/objdir/gcc/../lib/gcc/../../lib/gcc/sparc64-unknown-linux/4.6.3/include"
ignoring nonexistent directory
"/tmp/objdir/gcc/../lib/gcc/../../lib/gcc/sparc64-unknown-linux/4.6.3/include-fixed"
ignoring nonexistent directory
"/tmp/objdir/gcc/../lib/gcc/../../lib/gcc/sparc64-unknown-linux/4.6.3/../../../../sparc64-unknown-linux/sys-include"
ignoring nonexistent directory
"/tmp/objdir/gcc/../lib/gcc/../../lib/gcc/sparc64-unknown-linux/4.6.3/../../../../sparc64-unknown-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /tmp/objdir/gcc/include
 /tmp/objdir/gcc/include-fixed
End of search list.
GNU C (GCC) version 4.6.3 20120224 (prerelease) (sparc64-unknown-linux)
compiled by GNU C version 4.5.4 20120223 (prerelease), GMP version
5.0.4, MPFR version 3.1.0-p4, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 13caed9ea010fbdbe7751ee2ff3cc0c2
pr52425-2.c:62:1: internal compiler error: output_operand: invalid expression
as operand

Running cc1 within gdb with a breakpoint on output_operand_lossage:

Breakpoint 1, output_operand_lossage (cmsgid=0x8639346 "invalid expression as
operand") at /tmp/gcc-4.6-20120224/gcc/final.c:3076
3076{
Missing separate debuginfos, use: debuginfo-install glibc-2.13-2.i686
(gdb) bt
#0  output_operand_lossage (cmsgid=0x8639346 "invalid expression as operand")
at /tmp/gcc-4.6-20120224/gcc/final.c:3076
#1  0x081977bc in output_addr_const (file=0x88281d0, x=0xb7df98f4) at
/tmp/gcc-4.6-20120224/gcc/final.c:3634
#2  0x08133447 in dw2_asm_output_addr_rtx (size=4, addr=0xb7df98f4,
comment=0x0) at /tmp/gcc-4.6-20120224/gcc/dwarf2asm.c:282
#3  0x0813c302 in output_loc_operands (loc=0xb7d69b2c, for_eh_or_skip=) at /tmp/gcc-4.6-20120224/gcc/dwarf2out.c:5258
#4  output_loc_sequence (loc=0xb7d69b2c, for_eh_or_skip=)
at /tmp/gcc-4.6-20120224/gcc/dwarf2out.c:5317
#5  0x0813c8db in output_loc_list (die=) at
/tmp/gcc-4.6-20120224/gcc/dwarf2out.

[Bug testsuite/45988] gfortran.dg/vect/fast-math-pr38968.f90 times out on 32-bit Solaris 10/x86

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2012-03-02
 CC||ubizjak at gmail dot com
Version|4.6.0   |4.7.0
 Resolution|FIXED   |
 Ever Confirmed|0   |1

--- Comment #4 from Rainer Orth  2012-03-02 16:24:24 UTC 
---
I'm still seeing this bug on a particular machine, sometimes also for the
64-bit
case.

E.g. on zingana (4 x Quad-Core 2.93 GHz Intel Xeon X7350 running Solaris 10),
fast-math-pr38968.exe takes

real1:38.46
user1:37.61
sys0.53

The exact same binary and libraries on arenal (8 x Dual-Core 2.593 GHz AMD
Opteron 8218 running Solaris 11) takes

real  38.09
user  37.60
sys0.40

instead.  I've used the collect tool from the Studio 12.3 compilers to
investigate
and find that a single insn seems to dominate the runtime:

On zingana:

## 64.92564.925 [?]   400f0c:  movaps  0x10(%rcx,%rax),%xmm1

On arenal:

## 13.81013.810 [?]   400f0c:  movaps  0x10(%rcx,%rax),%xmm1

I'll attach the complete profiles.

  Rainer

[Bug testsuite/45988] gfortran.dg/vect/fast-math-pr38968.f90 times out on 32-bit Solaris 10/x86

[ro at gcc dot gnu.org]

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

--- Comment #6 from Rainer Orth  2012-03-02 16:25:59 UTC 
---
Created attachment 26811
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26811
profile on arenal

[Bug testsuite/45988] gfortran.dg/vect/fast-math-pr38968.f90 times out on 32-bit Solaris 10/x86

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  2012-03-02 16:25:21 UTC 
---
Created attachment 26810
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26810
profile on zingana

[Bug target/45988] gfortran.dg/vect/fast-math-pr38968.f90 times out on 32-bit Solaris 10/x86

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

  Component|testsuite   |target

--- Comment #7 from Rainer Orth  2012-03-02 16:28:51 UTC 
---
Not a testsuite issue.

[Bug libstdc++/52456] FAIL: libstdc++-abi/abi_check

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||ro at CeBiTec dot
   ||Uni-Bielefeld.DE

--- Comment #1 from Paolo Carlini  2012-03-02 
16:47:44 UTC ---
And the undesignated symbols are...? Is the issue recent?

[Bug libstdc++/52456] FAIL: libstdc++-abi/abi_check

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-03-02 16:56:23 UTC ---
> --- Comment #1 from Paolo Carlini  
> 2012-03-02 16:47:44 UTC ---
> And the undesignated symbols are...? Is the issue recent?

I suppose the symbols are from GLIBCXX_3.4.16.  If (as has been the case
for Solaris until very recently) the HP-PA Linux baselines were only
updated immediately before a minor (X.Y.0) release, the only contain
symbols up to GLIBCXX_3.4.15, which was how 4.6.0 was released.
check_abi (incorrectly IMO) flags GLIBCXX_3.4.16 symbols as
incompatible.

Rainer

[Bug libstdc++/52456] FAIL: libstdc++-abi/abi_check

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||bkoz at gcc dot gnu.org, ro
   ||at gcc dot gnu.org

--- Comment #3 from Rainer Orth  2012-03-02 16:58:37 UTC 
---
Benjamin, what do you think?

[Bug libstdc++/52456] FAIL: libstdc++-abi/abi_check

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2012-03-02 
17:00:17 UTC ---
Indeed (sorry) the "troublesome" (ie, leading to FAIL) symbols seem the 
ones, on x86_64-linux too we have two  and no FAIL.

[Bug target/46716] [4.4/4.5/4.6/4.7/4.8 Regression] wrong code generated with -mno-sse2 -m64

[uros at gcc dot gnu.org]

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

--- Comment #9 from uros at gcc dot gnu.org 2012-03-02 17:03:44 UTC ---
Author: uros
Date: Fri Mar  2 17:03:36 2012
New Revision: 184802

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184802
Log:
PR target/46716
* config/i386/i386.c (construct_container): Use gen_reg_or_parallel
to pass the argument in the register of "natural" mode.

testsuite/ChangeLog:

PR target/46716
* gcc.target/i386/pr46176.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr46716.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/52456] FAIL: libstdc++-abi/abi_check

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2012-03-02 
17:03:22 UTC ---
(by the way, while we are at it, on x86_64-linux I also currently have 1
, no FAIL, when building --enable-libstdcxx-time=rt, I suppose it's
fine)

[Bug c++/52458] [c++0x] compiler fails on for(:*this) with non-public inheritance with message: Internal compiler error: Error reporting routines re-entered.

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2012-03-02 
17:06:57 UTC ---
(In reply to comment #5)
> but this was a bug so I post it. It's pity MinGW updated only to 4.6.2.

The newest GCC release, 4.6.3, was only released yesterday!

[Bug middle-end/52463] New: libitm.c/memcpy-1.c FAILs

[ro at gcc dot gnu.org]

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

 Bug #: 52463
   Summary: libitm.c/memcpy-1.c FAILs
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: al...@gcc.gnu.org
  Host: i386-pc-solaris2.1[01], sparc-sun-solaris2.11
Target: i386-pc-solaris2.1[01], sparc-sun-solaris2.11
 Build: i386-pc-solaris2.1[01], sparc-sun-solaris2.11


Since 20120301, libitm.c/memcpy-1.c started to FAIL on Solaris/x86 and SPARC
in various ways:

* On 32-bit Solaris 10 and 11, SPARC and x86, the compilation never terminates:

WARNING: program timed out.
FAIL: libitm.c/memcpy-1.c (test for excess errors)
WARNING: libitm.c/memcpy-1.c compilation failed to produce executable

* On 64-bit Solaris 10/x86, I get an ICE:

FAIL: libitm.c/memcpy-1.c (internal compiler error)
FAIL: libitm.c/memcpy-1.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/libitm/testsuite/libitm.c/memcpy-1.c:93:5: internal
compiler error: Segmentation Fault

  The ICE vanishes with -v and/or -save-temps.

The problem is also present on the 4.7 branch.

  Rainer

[Bug regression/52383] [4.6 Regression] miscompiles Perl on m68k

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-03-02
 Ever Confirmed|0   |1

--- Comment #2 from Andreas Schwab  2012-03-02 17:13:36 
UTC ---
I'm unable to reproduce that.

[Bug target/49461] boehm-gc and gcj incompatible with pie

[mrs at gcc dot gnu.org]

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

--- Comment #14 from mrs at gcc dot gnu.org  2012-03-02 
18:21:47 UTC ---
Author: mrs
Date: Fri Mar  2 18:21:41 2012
New Revision: 184809

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184809
Log:
2012-03-02  Jack Howarth  

Backport from mainline
2012-02-23  Patrick Marlier  
Jack Howarth  

PR boehm-gc/52179
* include/gc_config.h.in: Undefine HAVE_PTHREAD_GET_STACKADDR_NP.
* include/private/gcconfig.h (DARWIN): Define STACKBOTTOM with
pthread_get_stackaddr_np when available.
* configure.ac (THREADS): Check availability of
pthread_get_stackaddr_np.
* configure: Regenerate.

2012-03-02  Jack Howarth  

Backport from mainline
2012-02-23  Patrick Marlier  
   Jack Howarth  

PR target/49461
* configure.ac (SYSTEMSPEC): No longer pass -no_pie for darwin11.
* configure: Regenerate.

Modified:
branches/gcc-4_6-branch/boehm-gc/ChangeLog
branches/gcc-4_6-branch/boehm-gc/configure
branches/gcc-4_6-branch/boehm-gc/configure.ac
branches/gcc-4_6-branch/boehm-gc/include/gc_config.h.in
branches/gcc-4_6-branch/boehm-gc/include/private/gcconfig.h
branches/gcc-4_6-branch/libjava/ChangeLog
branches/gcc-4_6-branch/libjava/configure
branches/gcc-4_6-branch/libjava/configure.ac

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[mrs at gcc dot gnu.org]

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

--- Comment #29 from mrs at gcc dot gnu.org  2012-03-02 
18:21:46 UTC ---
Author: mrs
Date: Fri Mar  2 18:21:41 2012
New Revision: 184809

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184809
Log:
2012-03-02  Jack Howarth  

Backport from mainline
2012-02-23  Patrick Marlier  
Jack Howarth  

PR boehm-gc/52179
* include/gc_config.h.in: Undefine HAVE_PTHREAD_GET_STACKADDR_NP.
* include/private/gcconfig.h (DARWIN): Define STACKBOTTOM with
pthread_get_stackaddr_np when available.
* configure.ac (THREADS): Check availability of
pthread_get_stackaddr_np.
* configure: Regenerate.

2012-03-02  Jack Howarth  

Backport from mainline
2012-02-23  Patrick Marlier  
   Jack Howarth  

PR target/49461
* configure.ac (SYSTEMSPEC): No longer pass -no_pie for darwin11.
* configure: Regenerate.

Modified:
branches/gcc-4_6-branch/boehm-gc/ChangeLog
branches/gcc-4_6-branch/boehm-gc/configure
branches/gcc-4_6-branch/boehm-gc/configure.ac
branches/gcc-4_6-branch/boehm-gc/include/gc_config.h.in
branches/gcc-4_6-branch/boehm-gc/include/private/gcconfig.h
branches/gcc-4_6-branch/libjava/ChangeLog
branches/gcc-4_6-branch/libjava/configure
branches/gcc-4_6-branch/libjava/configure.ac

[Bug target/49461] boehm-gc and gcj incompatible with pie

[mrs at gcc dot gnu.org]

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

--- Comment #15 from mrs at gcc dot gnu.org  2012-03-02 
18:30:44 UTC ---
libjava is back to being pie in 4.6.4 and 4.7.0.

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[mrs at gcc dot gnu.org]

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

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

   What|Removed |Added

 CC||mrs at gcc dot gnu.org
  Known to work||4.6.4, 4.7.0

--- Comment #30 from mrs at gcc dot gnu.org  2012-03-02 
18:35:01 UTC ---
Fixed in 4.6.4 and 4.7.0.

[Bug c++/52464] New: When I compile my source codes with -O3 option, the compiler fails. This does not occur if I use -O2

[bli at cs dot wisc.edu]

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

 Bug #: 52464
   Summary: When I compile my source codes with -O3 option, the
compiler fails. This does not occur if I use -O2
Classification: Unclassified
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b...@cs.wisc.edu


I attached my software package in the attachment. You just need to type 
"make rsem-parse-alignments" to trigger the bug. Thanks!



$ g++ -v -save-temps -Wall -O3 -ffast-math -c -I. parseIt.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.5.3/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with:
/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/configure
--srcdir=/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/gcc4 -C
--datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v
--with-gmp=/usr --with-mpfr=/usr --enable-bootstrap
--enable-version-specific-runtime-libs --libexecdir=/usr/lib --enable-static
--enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld
--with-gnu-as --with-dwarf2 --disable-sjlj-exceptions
--enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite
--enable-lto --enable-java-awt=gtk --disable-symvers --enable-libjava
--program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada
--enable-threads=posix --with-arch=i686 --with-tune=generic
--enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4
CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind
--with-ecj-jar=/usr/share/java/ecj.jar
Thread model: posix
gcc version 4.5.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-O3' '-ffast-math' '-c' '-I.'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1plus.exe -E -quiet -v -I. -D__CYGWIN32__
-D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter
/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api -idirafter
/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/lib/../../include/w32api
parseIt.cpp -mtune=generic -march=i686 -Wall -ffast-math -O3 -fpch-preprocess
-o parseIt.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/include"
ignoring duplicate directory
"/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
 .
 /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++
 /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin
 /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/backward
 /usr/lib/gcc/i686-pc-cygwin/4.5.3/include
 /usr/lib/gcc/i686-pc-cygwin/4.5.3/include-fixed
 /usr/include
 /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-O3' '-ffast-math' '-c' '-I.'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1plus.exe -fpreprocessed parseIt.ii -quiet
-dumpbase parseIt.cpp -mtune=generic -march=i686 -auxbase parseIt -O3 -Wall
-version -ffast-math -o parseIt.s
GNU C++ (GCC) version 4.5.3 (i686-pc-cygwin)
compiled by GNU C version 4.5.3, GMP version 4.3.2, MPFR version
3.0.1-p4, MPC version 0.8
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.5.3 (i686-pc-cygwin)
compiled by GNU C version 4.5.3, GMP version 4.3.2, MPFR version
3.0.1-p4, MPC version 0.8
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2eb50487139b9f2ceb9af473175cad84
In file included from parseIt.cpp:9:0:
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/fstream: In constructor
‘std::basic_ofstream<_CharT, _Traits>::basic_ofstream(const char*,
std::ios_base::openmode) [with _CharT = char, _Traits = std::char_traits,
std::ios_base::openmode = std::_Ios_Openmode]’:
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/fstream:701:4: internal compiler
error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/52464] When I compile my source codes with -O3 option, the compiler fails. This does not occur if I use -O2

[bli at cs dot wisc.edu]

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

--- Comment #1 from bli at cs dot wisc.edu 2012-03-02 19:01:32 UTC ---
Please find the source code from the URL listed, or :

http://deweylab.biostat.wisc.edu/rsem/rsem-1.1.17.bug.tar.gz


Do the following to trigger the bug:

tar -xzf rsem-1.1.17.bug.tar.gz
make rsem-parse-alignments

[Bug rtl-optimization/29589] incorrect conversion of (ior (ashiftrt (plus ...))) in combine.c

[bernhard.kaindl at thalesgroup dot com]

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

Bernhard Kaindl  changed:

   What|Removed |Added

 CC||bernhard.kaindl at
   ||thalesgroup dot com

--- Comment #10 from Bernhard Kaindl  
2012-03-02 19:16:13 UTC ---
Verification using gcc-4.4.6 --target=powerpc-linux --host=i686-linux:

The test case works with -O2, -Os as well as -O3 -no-inline with this
cross-gcc,
but when using -O1, the test case still calls abort() -> foo returns 0 in gdb,
so it has been improved, but not completely fixed in 4.4.6

[Bug middle-end/27321] Compare against constant infinity fails with IBM long double format

[bernhard.kaindl at thalesgroup dot com]

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

Bernhard Kaindl  changed:

   What|Removed |Added

 CC||bernhard.kaindl at
   ||thalesgroup dot com

--- Comment #3 from Bernhard Kaindl  
2012-03-02 19:25:55 UTC ---
Verification using powerpc-linux-gcc-4.4.6 (--host=i686-linux):

Testcase works, it seems this may be fixed. Suggest closing after soon 6 years.

[Bug middle-end/50335] ICE in psct_dynamic_dim, at graphite-poly.h:659

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #14 from Maxim Kuvyrkov  2012-03-02 
20:36:12 UTC ---
Fixed by removing loop flattening optimization.  The -floop-flatten flag no
does nothing.

[Bug target/31640] cache block alignment is too aggressive on sh-elf

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo  2012-03-02 20:56:50 
UTC ---
Author: olegendo
Date: Fri Mar  2 20:56:46 2012
New Revision: 184825

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184825
Log:
PR target/31640
* config/sh/sh.h (LOOP_ALIGN): Move logic to sh_loop_align.
* config/sh/sh.c: Update copyright notice dates.
(sh_loop_align): Add logic from LOOP_ALIGN.  Don't disable loop
alignment for TARGET_HARD_SH4.
(sh_option_override): Reduce default function alignment.  Set 
loop alignment to 4 bytes when not optimizing for size.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.h

[Bug bootstrap/49486] [4.7 Regression] Bootstrap failure

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  2012-03-02 21:21:17 
UTC ---
Author: olegendo
Date: Fri Mar  2 21:21:13 2012
New Revision: 184829

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184829
Log:
PR target/49486
* config/sh/sh.md (negdi2): Add TARGET_SH1 condition.
(absdi2): New expander.
(*absdi2, *negabsdi2, negdi_cond): New insns and splits.
* gcc.target/sh/pr49468-si.c: Skip unsupported test for SH64.
* gcc.target/sh/pr49468-di.c: New.


Added:
trunk/gcc/testsuite/gcc.target/sh/pr49468-di.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/sh/pr49468-si.c

[Bug target/51244] SH Target: Inefficient conditional branch

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

  Attachment #26191|0   |1
is obsolete||

--- Comment #9 from Oleg Endo  2012-03-02 21:56:38 
UTC ---
Created attachment 26812
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26812
Proposed patch

I've tested this patch again against rev 184764 (GCC 4.7) with

make -k check RUNTESTFLAGS="--target_board=sh-sim\{
-m2/-ml,-m2/-mb,-m2a-single/-mb,-m4-single/-ml,
-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}"

Surprisingly, it fixes the following libstdc++ tests.

For all sub targets:
23_containers/forward_list/requirements/exception/basic.cc
23_containers/forward_list/requirements/exception/propagation_consistent.cc
23_containers/list/requirements/exception/basic.cc
23_containers/list/requirements/exception/propagation_consistent.cc
23_containers/multiset/requirements/exception/basic.cc
23_containers/multiset/requirements/exception/propagation_consistent.cc
23_containers/unordered_map/requirements/exception/propagation_consistent.cc
23_containers/unordered_multimap/requirements/exception/basic.cc
23_containers/unordered_multiset/requirements/exception/basic.cc
23_containers/unordered_multiset/requirements/exception/propagation_consistent.cc
23_containers/unordered_set/requirements/exception/propagation_consistent.cc
ext/pb_ds/regression/list_update_map_rand.cc
ext/pb_ds/regression/list_update_set_rand.cc

For -m4a-single and -m4-single (-ml and -mb):
23_containers/forward_list/requirements/exception/basic.cc
23_containers/forward_list/requirements/exception/propagation_consistent.cc
23_containers/list/requirements/exception/basic.cc
23_containers/list/requirements/exception/propagation_consistent.cc
23_containers/multiset/requirements/exception/basic.cc
23_containers/multiset/requirements/exception/propagation_consistent.cc

However, it also introduces two new of new failures.

For all sub targets:
FAIL: 21_strings/basic_string/cons/char/6.cc execution test

For -m4a-single and -m4-single (-ml and -mb):
FAIL: 22_locale/ctype/is/char/3.cc execution test

I'm looking into what is happening in the two cases.

[Bug fortran/47030] !GCC$ Attributes do not work for COMMON variables in procedures and BLOCK DATA

[eh.toussaint at gmail dot com]

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

Erik Toussaint  changed:

   What|Removed |Added

 CC||eh.toussaint at gmail dot
   ||com

--- Comment #3 from Erik Toussaint  2012-03-02 
22:17:52 UTC ---
(In reply to comment #0)

For both program units, if I add 'implicit none' I get the following error:

!GCC$ attributes dllexport :: mydata
1
Error: Symbol 'mydata' at (1) has no IMPLICIT type

So 'mydata' is treated as the identifier of a local entity. Which makes sense,
because a common block and a local entity can have the same name (with certain
restrictions; see 16.3.1 and 16.3.2 in f2008).

Looking at the syntax of the Intel Fortran compiler, the name of the common
block has to be between slashes:

!DEC$ ATTRIBUTES DLLEXPORT :: /X/

http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/fortran/win/compiler_f/bldaps_for/win/bldaps_share_datadlls.htm

Trying this with gfortran gives an error:

!GCC$ attributes dllexport :: /mydata/
   1
Error: Invalid character in name at (1)


P.s.:

> !-
> module m
>real :: x
>common /mydata/ x
>!GCC$ attributes dllexport :: mydata
> end module
> !-
> 
> I get the warning:
> 
>   f951: warning: ‘dllexport’ attribute directive ignored [-Wattributes]

I get an error (I'm using MinGW GCC 4.6.2):

m.f90:5:0: error: external linkage required for symbol 'mydata' because of
'dlle
xport' attribute

[Bug target/52457] Wrong VSX code generation bug when compiled with -O1 -m32 -mcpu=power7

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #3 from Peter Bergner  2012-03-02 
22:46:25 UTC ---
Patch was committed to trunk and the 4.7, 4.6 and 4.5 release branches.  Bah, I
forgot to include the PR# in the ChangeLog, so you won't see the automatic
confirmation note here. :(

[Bug rtl-optimization/48596] [4.7/4.8 Regression] [SH] unable to find a register to spill in class 'FPUL_REGS'

[kkojima at gcc dot gnu.org]

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

--- Comment #6 from Kazumoto Kojima  2012-03-02 
23:59:16 UTC ---
Author: kkojima
Date: Fri Mar  2 23:59:08 2012
New Revision: 184844

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184844
Log:
PR target/48596
PR target/48806
* config/sh/sh.c (sh_register_move_cost): Increase cost between
GENERAL_REGS and FP_REGS for SImode.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c

[Bug target/48806] ICE in reload_cse_simplify_operands, at postreload.c:403

[kkojima at gcc dot gnu.org]

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

--- Comment #2 from Kazumoto Kojima  2012-03-02 
23:59:17 UTC ---
Author: kkojima
Date: Fri Mar  2 23:59:08 2012
New Revision: 184844

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184844
Log:
PR target/48596
PR target/48806
* config/sh/sh.c (sh_register_move_cost): Increase cost between
GENERAL_REGS and FP_REGS for SImode.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c

[Bug libstdc++/52456] FAIL: libstdc++-abi/abi_check

[dave.anglin at bell dot net]

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

--- Comment #6 from dave.anglin at bell dot net 2012-03-03 00:05:34 UTC ---
On 2-Mar-12, at 11:47 AM, paolo.carlini at oracle dot com wrote:

> And the undesignated symbols are...? Is the issue recent?


Attached is the symbol diff.  The undesignated symbols are:

2 undesignated symbols
0
_ZSt11__once_call
std::__once_call
version status: compatible
GLIBCXX_3.4.11
type: tls
type size: 4
status: undesignated

1
_ZSt15__once_callable
std::__once_callable
version status: compatible
GLIBCXX_3.4.11
type: tls
type size: 4
status: undesignated

Dave
--
John David Anglindave.ang...@bell.net

[Bug c++/52464] When I compile my source codes with -O3 option, the compiler fails. This does not occur if I use -O2

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-03-03
 Ever Confirmed|0   |1

--- Comment #2 from Paolo Carlini  2012-03-03 
00:32:41 UTC ---
Please follow the bug reporting instructions http://gcc.gnu.org/bugs/#report in
particular please attach a self-contained preprocessed file, thanks.

[Bug c++/52464] When I compile my source codes with -O3 option, the compiler fails. This does not occur if I use -O2

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Severity|blocker |normal

[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)

[oleg at smolsky dot net]

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

--- Comment #34 from oleg at smolsky dot net 2012-03-03 02:19:21 UTC ---
OK, here are some benchmark numbers for the test compiled verbatim with 
g++41/g++463 -O2:

$ time ./test41
rv=4243767296

real0m6.063s
user0m6.058s
sys 0m0.001s

$ time ./test46
rv=4243767296

real0m11.425s
user0m11.415s
sys 0m0.003s

$ time ./test46-fast #(ie built it with -DFAST_VER)
rv=4243767296

real0m11.389s
user0m11.383s
sys 0m0.003s

Let me see how the sample can be digested further down...

[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)

[oleg at smolsky dot net]

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

--- Comment #35 from oleg at smolsky dot net 2012-03-03 02:45:15 UTC ---
Here is a smaller version. BTW, I've noticed another regression in 
optimization in v4.1 when using a const global...

[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)

[oleg at smolsky dot net]

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

--- Comment #36 from oleg at smolsky dot net 2012-03-03 02:59:11 UTC ---
Here is the code emitted by g++ 4.6.3 for smaller_test.cpp (attached to 
the bug)

  unsigned int test_constant<> proc near
 mov r9d, cs:iterations
 xor r8d, r8d
 xor eax, eax
 testr9d, r9d
 jle short locret_400552
 db  66h, 66h, 66h
 nop
 db  66h, 66h
 nop

loc_400528:
 xor ecx, ecx
 xor edx, edx
 testesi, esi
 jle short loc_40054E

loc_400530:
 add edx, 0Ah
 add dl, [rdi+rcx]
 add rcx, 1
 cmp esi, ecx
 jg  short loc_400530
 movsx   edx, dl

loc_400541:
 add r8d, 1
 add eax, edx
 cmp r8d, r9d
 jnz short loc_400528
 rep retn

loc_40054E:
 xor edx, edx
 jmp short loc_400541

locret_400552:
 rep retn

[Bug libfortran/36044] user-requested backtrace

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||patch
URL||http://gcc.gnu.org/ml/fortr
   ||an/2012-03/msg00015.html
 CC||fxcoudert at gcc dot
   ||gnu.org

--- Comment #7 from Francois-Xavier Coudert  
2012-03-03 07:45:51 UTC ---
Patch was proposed at http://gcc.gnu.org/ml/fortran/2012-03/msg00015.html