[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #18 from Kai Tietz  2011-02-15 08:03:05 
UTC ---
Well, I see the issue you are describing here, but it isn't any longer related
to this PR. So please open an new PR for it.

So I close this bug as fixed.

Regards,
Kai

PS:I assume that you won't have the issue by using -static option on gcc
command-line.

[Bug ada/47748] New: Legal program rejected, ARM 12.7(3/2): instantiating a generic package with "others => <>"

[ludo...@ludovic-brenta.org]

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

   Summary: Legal program rejected, ARM 12.7(3/2): instantiating a
generic package with "others => <>"
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ludo...@ludovic-brenta.org


This bug was first reported on comp.lang.ada and confirmed:

package formalpkg is

   generic
  type T is private;
  with procedure P (X : T) is <>;
   package F is
   end F;

   generic
  with package FA is new F (others => <>); -- line 17
   package B is
   end B;

   procedure P1 (X : Character) is null;
   package F1 is new F (Character, P1); -- use P => P1

   package B1 is new B (F1); -- Error !!

   procedure P (X : Character) is null;
   package F2 is new F (Character); -- P => P

   package B2 is new B (F2); -- OK

end formalpkg;

% gnatmake formalpkg.ads
gcc -c formalpkg.ads
formalpkg.ads:17:25: actual for "P" in actual instance does not match formal
gnatmake: "formalpkg.ads" compilation error 

On line 17, replacing "others => <>" with just "<>" makes the package compile
cleanly.

[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'

[dongsheng.song at gmail dot com]

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

--- Comment #19 from Dongsheng Song  
2011-02-15 08:23:35 UTC ---
(In reply to comment #18)
> Well, I see the issue you are describing here, but it isn't any longer related
> to this PR. So please open an new PR for it.
> 
> So I close this bug as fixed.
> 
> Regards,
> Kai
> 
> PS:I assume that you won't have the issue by using -static option on gcc
> command-line.

No, maybe the another bug mix up you eyes:-)

Even for static link, lto still not works fine for Hello.c:

C:\>g++ -pipe -O2 -flto -o Hello.c.exe Hello.c
C:\>Hello.c.exe


C:\>g++ -pipe -O2 -flto -static -o Hello.c.static.exe Hello.c
C:\>Hello.c.static.exe


C:\>g++ -pipe -O2 -o Hello.exe Hello.c
C:\>Hello.exe
Hello, World!

[Bug c++/47749] New: Wrong function return value

[elpa.rizzo at gmail dot com]

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

   Summary: Wrong function return value
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: elpa.ri...@gmail.com


This function returns always false, also if parameter is true
Target is: arm-unknown-linux-uclibc
If you:
- define string s inside if loop
- or instance string s as static
- or add an explicit final return statement
- or don't use string s
the function works correctly.
Examining the source code, one unwinding assembler statement is missing.


#include 

using namespace std;

bool fn_bad(bool flag)
{
string s;
if(flag)
{
s = "A";
return true;
}
}

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus  2011-02-15 
09:07:58 UTC ---
(In reply to comment #8)
> Created attachment 23344 [details]
> Hackish brute-force patch

Note: This patch causes (not very surprisingly) file-read problems, e.g. for
Polyhedron's aermod.f90 (which reads aermod.inp). Thus, do not use it for
production code.

[Bug c++/47749] Wrong function return value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|major   |normal

--- Comment #1 from Jonathan Wakely  2011-02-15 
09:14:10 UTC ---
Severity is not "major"

Your program has undefined behaviour if you call the function with flag=false
and use the return value.

[Bug c++/47749] Wrong function return value

[elpa.rizzo at gmail dot com]

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

--- Comment #2 from Davide Rizzo  2011-02-15 
09:27:24 UTC ---
Yes, but the big problem is that the function return false also if you call
it with flag=true.

2011/2/15 redi at gcc dot gnu.org 

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47749
>
> Jonathan Wakely  changed:
>
>   What|Removed |Added
>
> 
>   Severity|major   |normal
>
> --- Comment #1 from Jonathan Wakely  2011-02-15
> 09:14:10 UTC ---
> Severity is not "major"
>
> Your program has undefined behaviour if you call the function with
> flag=false
> and use the return value.
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.
>

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jb at gcc dot gnu.org]

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

--- Comment #11 from Janne Blomqvist  2011-02-15 
09:42:12 UTC ---
Unfortunately I don't think I'll have time to look into it this week.

As can be seen from Tobias patch, reading one character at a time is very slow.
But, the comment in read_sf() is wrong, it's not actually needed to read one
character at a time; what we need to do is to handle short reads correctly.

One fix, I suspect, would be to convert read_sf() to use fbuf_getc() instead,
which gives the impression of reading a character at a time, even though fbuf
takes care of doing buffered reads in the background. But in order to do that,
the read_sf() API needs to be changed so that a buffer is passed as an
argument, and this buffer is then filled with data, rather than returning a
pointer to the fbuf buffer.

[Bug pch/14940] PCH largefile test fails on various platforms

[ro at gcc dot gnu.org]

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

--- Comment #43 from Rainer Orth  2011-02-15 09:49:22 
UTC ---
Author: ro
Date: Tue Feb 15 09:49:14 2011
New Revision: 170166

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170166
Log:
PR pch/14940
* config/alpha/host-osf.c: New file.
* config/alpha/x-osf: New file.
* config.host (alpha*-dec-osf*): Use it.

Added:
trunk/gcc/config/alpha/host-osf.c
trunk/gcc/config/alpha/x-osf
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.host

[Bug pch/14940] PCH largefile test fails on various platforms

[ro at gcc dot gnu.org]

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

--- Comment #44 from Rainer Orth  2011-02-15 09:52:04 
UTC ---
Author: ro
Date: Tue Feb 15 09:51:58 2011
New Revision: 170167

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170167
Log:
PR pch/14940
* config/alpha/host-osf.c: New file.
* config/alpha/x-osf: New file.
* config.host (alpha*-dec-osf*): Use it.

Added:
branches/gcc-4_5-branch/gcc/config/alpha/host-osf.c
branches/gcc-4_5-branch/gcc/config/alpha/x-osf
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config.host

[Bug pch/14940] PCH largefile test fails on various platforms

[ro at gcc dot gnu.org]

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

--- Comment #45 from Rainer Orth  2011-02-15 09:58:04 
UTC ---
Author: ro
Date: Tue Feb 15 09:58:01 2011
New Revision: 170168

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170168
Log:
PR pch/14940
* config/alpha/host-osf.c: New file.
* config/alpha/x-osf: New file.
* config.host (alpha*-dec-osf*): Use it.

Added:
branches/gcc-4_4-branch/gcc/config/alpha/host-osf.c
branches/gcc-4_4-branch/gcc/config/alpha/x-osf
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config.host

[Bug fortran/47745] [OOP] Segfault with CLASS(*) and derived type dummy arguments

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.15 10:09:26
 Ever Confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org 2011-02-15 10:09:26 UTC ---
With 4.6 trunk I get:


crashme.f08:8.23:

class(*), intent(in) :: x
   1
Error: Invalid character in name at (1)
crashme.f08:6.29:

class(T) function add(d, x)
 1
Error: CLASS variable 'add' at (1) must be dummy, allocatable or pointer
f951: internal compiler error: Segmentation fault



I think the test case is actually invalid due to C407 in the Fortran 2008
standard (cf. second error message):

C407 An entity declared with the CLASS keyword shall be a dummy argument or
have the ALLOCATABLE or POINTER attribute.

[Bug fortran/47745] [OOP] Segfault with CLASS(*) and derived type dummy arguments

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from janus at gcc dot gnu.org 2011-02-15 10:22:33 UTC ---
(In reply to comment #1)
> Note: CLASS(*) -- i.e. unlimited polymorphism -- is not yet supported; 
> however,
> there should be no an internal compiler error.

Right. We definitely need a better rejection of CLASS(*). Draft patch:

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c(revision 170156)
+++ gcc/fortran/decl.c(working copy)
@@ -2613,6 +2613,16 @@ gfc_match_decl_type_spec (gfc_typespec *ts, int im
 ts->type = BT_DERIVED;
   else
 {
+  /* Match CLASS declarations.  */
+  m = gfc_match (" class ( * )");
+  if (m == MATCH_ERROR)
+return MATCH_ERROR;
+  else if (m == MATCH_YES)
+{
+  gfc_fatal_error ("Unlimited polymorphism at %C not yet supported");
+  return MATCH_ERROR;
+}
+
   m = gfc_match (" class ( %n )", name);
   if (m != MATCH_YES)
 return m;

[Bug c++/47749] Wrong function return value

[ibolton at gcc dot gnu.org]

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

Ian Bolton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.02.15 10:25:35
 CC||ibolton at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from Ian Bolton  2011-02-15 10:25:35 
UTC ---
What compile flags are you using?  Have you tried gcc 4.5?

[Bug fortran/47745] [OOP] Segfault with CLASS(*) and derived type dummy arguments

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #4 from janus at gcc dot gnu.org 2011-02-15 10:26:40 UTC ---
However, the ICE itself seems unrelated to the CLASS(*) error. It still happens
with the following reduction:


  type, abstract :: T 
  end type T
contains
  class(T) function add()
add = 1
  end function
end



  class(T) function add()
   1
Error: CLASS variable 'add' at (1) must be dummy, allocatable or pointer
f951: internal compiler error: Segmentation fault


It is correctly rejected, but then one gets an ICE (triggered by the
assignment).

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

[burnus at gcc dot gnu.org]

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

   Summary: testsuite/gfortran.dg: dg-warning and dg-error should
be distinguished
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: bur...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
Blocks: 45743


Currently, dg-error and dg-warning are effectively treated as identical.

Adding the prefix to gcc/testsuite/lib/gfortran.exp (cf. e.g. objc.exp) is
enough to make them distinguishable.

However, the dg machinery expects that there is a column number - unless the
dg-error/warning starts with "0:". Cf. lib/gcc-dg.exp's process-message.

To mend this, one has to modify the regular expression in
gcc/testsuite/lib/gfortran-dg.exp

I have an (almost) working patch for that.

[Bug middle-end/47735] [4.5/4.6 Regression] Unnecessary adjustments to stack pointer

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.5.3

[Bug tree-optimization/47737] [4.6 Regression] wrong code with -funswitch-loops -fno-tree-dominator-opts -fgraphite-identity

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug tree-optimization/47738] ICE: verify_ssa failed: no immediate_use list with -O3 -fno-tree-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.02.15 11:09:19
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-02-15 
11:09:19 UTC ---
I'll have a look.

[Bug middle-end/47743] [4.6 Regression] PRE ICE in fold_convert_loc

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.02.15 11:15:13
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-02-15 
11:15:13 UTC ---
Mine.

[Bug c++/47749] Wrong function return value

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-02-15 
11:18:45 UTC ---
does adding

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

cause the testcase to abort at runtime?  Which flags are you using for
compiling?

[Bug middle-end/47581] [4.5/4.6 regression] Unnecessary adjustments to stack pointer

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2011-02-15 
11:46:14 UTC ---
Author: jakub
Date: Tue Feb 15 11:46:10 2011
New Revision: 170170

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170170
Log:
PR middle-end/47581
* config/i386/i386.c (ix86_compute_frame_size): Don't align offset
if frame size is 0 in a leaf function.

* gcc.target/i386/pr47581.c: New test.

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

[Bug fortran/47745] [OOP] Segfault with CLASS(*) and derived type dummy arguments

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org 2011-02-15 11:53:36 UTC ---
One can get rid of the ICE via these two hunks:


Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision 170169)
+++ gcc/fortran/interface.c(working copy)
@@ -2924,7 +2924,11 @@ matching_typebound_op (gfc_expr** tb_base,
 gfc_try result;

 if (base->expr->ts.type == BT_CLASS)
-  derived = CLASS_DATA (base->expr)->ts.u.derived;
+  {
+if (!gfc_expr_attr (base->expr).class_ok)
+  continue;
+derived = CLASS_DATA (base->expr)->ts.u.derived;
+  }
 else
   derived = base->expr->ts.u.derived;

 Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c(revision 170169)
+++ gcc/fortran/primary.c(working copy)
@@ -2033,7 +2033,7 @@ gfc_variable_attr (gfc_expr *expr, gfc_typespec *t
   sym = expr->symtree->n.sym;
   attr = sym->attr;

-  if (sym->ts.type == BT_CLASS)
+  if (sym->ts.type == BT_CLASS && sym->attr.class_ok)
 {
   dimension = CLASS_DATA (sym)->attr.dimension;
   pointer = CLASS_DATA (sym)->attr.class_pointer;

[Bug c++/47749] Wrong function return value

[elpa.rizzo at gmail dot com]

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

--- Comment #5 from Davide Rizzo  2011-02-15 
12:05:58 UTC ---
No, with this testcase it doesn't abort.
I think the return value is random not only with flag=false (that could be
acceptable), but also with flag=true.
I don't use any compiler flag, I tried with -O0, -O1, -O2 and -O3 but I
didn't notice any difference.
Unfortunately I cannot try other compiler's versions.
Comparing the arm assembler listings, in the failing version the statement
that restores the correct return value in the return register is missing.

2011/2/15 rguenth at gcc dot gnu.org 

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47749
>
> --- Comment #4 from Richard Guenther 
> 2011-02-15 11:18:45 UTC ---
> does adding
>
> extern "C" void abort (void);
> int main() { if (!fn_bad (true)) abort(); return 0; }
>
> cause the testcase to abort at runtime?  Which flags are you using for
> compiling?
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.
>

[Bug middle-end/47581] [4.5 regression] Unnecessary adjustments to stack pointer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Known to work||4.6.0
Summary|[4.5/4.6 regression]|[4.5 regression]
   |Unnecessary adjustments to  |Unnecessary adjustments to
   |stack pointer   |stack pointer
  Known to fail|4.6.0   |

--- Comment #12 from Jakub Jelinek  2011-02-15 
12:11:30 UTC ---
Fixed on the trunk so far.

[Bug middle-end/47743] [4.6 Regression] PRE ICE in fold_convert_loc

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-02-15 
13:04:50 UTC ---
Author: rguenth
Date: Tue Feb 15 13:04:47 2011
New Revision: 170173

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170173
Log:
2011-02-15  Richard Guenther  

PR tree-optimization/47743
* tree-ssa-pre.c (phi_translate_1): If we didn't get a value-number
for a non-type-compatible VN lookup bail out.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr47743.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug middle-end/47743] [4.6 Regression] PRE ICE in fold_convert_loc

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther  2011-02-15 
13:05:43 UTC ---
Fixed.

[Bug c/47751] New: Wrong code with -mcpu=8540 -mfloat-gprs=double -mspe -Os on PowerPC

[sebastian.hu...@embedded-brains.de]

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

   Summary: Wrong code with -mcpu=8540 -mfloat-gprs=double -mspe
-Os on PowerPC
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: powerpc-rtems4.11una


Created attachment 23349
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23349
Assembler code.

In the attached assembler file:

Line 371: Save of non-volatile registers via stmw 25,28(1)

Line 454: Restore of non-volatile registers via b _rest64gpr_25_x

This procedure is completely wrong, e.g. _rest64gpr_25_x loads the link
register from a wrong stack position with an arbitrary value.

[Bug c/47751] Wrong code with -mcpu=8540 -mfloat-gprs=double -mspe -Os on PowerPC

[sebastian.hu...@embedded-brains.de]

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

--- Comment #1 from Sebastian Huber  
2011-02-15 13:12:52 UTC ---
Created attachment 23350
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23350
C source code corresponding to the assembler code.

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

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  2011-02-15 
13:22:45 UTC ---
Author: hjl
Date: Tue Feb 15 13:22:41 2011
New Revision: 170175

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170175
Log:
Process (reg + const) base for TARGET_X32.

gcc/

2011-02-15  H.J. Lu  

PR target/47744
* config/i386/i386.c (ix86_decompose_address): Process
(reg + const) base for TARGET_X32.

gcc/testsuite/

2011-02-15  H.J. Lu  

PR target/47744
* gcc.dg/torture/pr47744.c: New.

Added:
branches/x32/gcc/testsuite/gcc.dg/torture/pr47744.c
Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/config/i386/i386.c
branches/x32/gcc/testsuite/ChangeLog.x32

[Bug preprocessor/47741] -I- option stated obsolete considered worrying

[richard_sharman at mitel dot com]

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

--- Comment #3 from Richard Sharman  
2011-02-15 13:44:38 UTC ---
> Oh and -iquote takes an argument.
Oh thanks!  How silly of me!   Thanks for the feedback. I did try 
searching for -I- by the way but it seemed to match everything with an I 
in it!  I tried quoting "-I-" but that didn't help.

Thanks
Richard

[Bug c++/47752] New: Non-dependent name is found in dependent base class although it should be rejected

[volker.simonis at gmail dot com]

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

   Summary: Non-dependent name is found in dependent base class
although it should be rejected
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: volker.simo...@gmail.com


Consider the following example:

===

template struct B {
  void f(int i) { }
  void f2() { }
};

template struct D : public B {
  int foo(int i) {
return i;
  }
  void g() {
// f(42);   // (1)
f(foo(42)); // (2)
// f2();// (3)
  }
}; 

struct E : public D {
  void h() {
g();
  }
};

=

This compiles fine with g++ 4.5.2.
If one of the lines (1) or (2) is uncommented, the compilation fails with:

dependent2.cpp:11: error: there are no arguments to ‘f’ that depend on a
template parameter, so a declaration of ‘f’ must be available
dependent2.cpp:13: error: there are no arguments to ‘f2’ that depend on a
template parameter, so a declaration of ‘f2’ must be available

I think the compilation of the call 'f(foo(42))' should fail for the same
reason.

Regards,
Volker

[Bug fortran/47745] [OOP] Segfault with CLASS(*) and derived type dummy arguments

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  2011-02-15 
13:57:47 UTC ---
If I did not do any mistake, the patch in comment #5 breaks at least
gfortran.dg/typebound_operator_6.f03:

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/typebound_operator_6.f03:44.13:

  LST = (A%PT .LT. B%PT)
 1
Error: Operands of comparison operator '.lt.' at (1) are CLASS(dat)/CLASS(dat)
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/typebound_operator_6.f03:52.14:

  USE NODE_MOD
  1
Fatal Error: Can't open module file 'node_mod.mod' for reading at (1): No such
file or directory

[Bug libstdc++/47753] New: Invalid 32bit libstdc++.dll.a on mingw-w64 target

[dongsheng.song at gmail dot com]

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

   Summary: Invalid 32bit libstdc++.dll.a on mingw-w64 target
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dongsheng.s...@gmail.com


Before 2011-02-13, both gcc-4.5 branch and trunk is fine to build 
mingw-w64/multilib target on i686-pc-linux-gnu host.

But now the file size of 32-bit libstdc++.dll.a is very small (2260 byte),
64-bit libstdc++.dll.a is OK:

Here is gcc-4.5 branch building result:

oracle@vc:~/tmp/gcc-4.5-windows_i686-linux-obj/gcc$ ls -la
./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++*
-rwxr-xr-x 1 oracle dba 5662948 Feb 15 21:34
./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++-6.dll
-rw-r--r-- 1 oracle dba 8874224 Feb 15 21:34
./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++.a
-rw-r--r-- 1 oracle dba2260 Feb 15 21:34
./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++.dll.a
lrwxrwxrwx 1 oracle dba  15 Feb 15 21:34
./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++.la -> ../libstdc++.la
-rw-r--r-- 1 oracle dba 986 Feb 15 21:34
./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++.lai
oracle@vc:~/tmp/gcc-4.5-windows_i686-linux-obj/gcc$ ls -la
./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++*
-rwxr-xr-x 1 oracle dba  7226445 Feb 15 21:35
./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++-6.dll
-rw-r--r-- 1 oracle dba 10478438 Feb 15 21:35
./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++.a
-rw-r--r-- 1 oracle dba  2591940 Feb 15 21:35
./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++.dll.a
lrwxrwxrwx 1 oracle dba   15 Feb 15 21:35
./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++.la -> ../libstdc++.la
-rw-r--r-- 1 oracle dba  986 Feb 15 21:35
./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++.lai


Here is gcc trunk building result:

oracle@vc:~/tmp/gcc-4.6-windows_i686-linux-obj/gcc$ ls -la
./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++*
-rwxr-xr-x 1 oracle dba 5257378 Feb 15 21:16
./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++-6.dll
-rw-r--r-- 1 oracle dba 8065534 Feb 15 21:16
./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++.a
-rw-r--r-- 1 oracle dba2260 Feb 15 21:16
./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++.dll.a
lrwxrwxrwx 1 oracle dba  15 Feb 15 21:16
./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++.la -> ../libstdc++.la
-rw-r--r-- 1 oracle dba 974 Feb 15 21:16
./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++.lai
oracle@vc:~/tmp/gcc-4.6-windows_i686-linux-obj/gcc$ ls -la
./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++*
-rwxr-xr-x 1 oracle dba  7228283 Feb 15 21:18
./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++-6.dll
-rw-r--r-- 1 oracle dba 10777424 Feb 15 21:18
./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++.a
-rw-r--r-- 1 oracle dba  2639980 Feb 15 21:18
./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++.dll.a
lrwxrwxrwx 1 oracle dba   15 Feb 15 21:18
./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++.la -> ../libstdc++.la
-rw-r--r-- 1 oracle dba  976 Feb 15 21:18
./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++.lai

Tested with the latest binutils.

[Bug libfortran/47716] libgfortran quadmath_weak.h not found on NetBSD 5.1

[laurent at guerby dot net]

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

--- Comment #4 from Laurent GUERBY  2011-02-15 
14:17:09 UTC ---
Tobias, the patch you mentionned did allow bootstrap with c,fortran and without
disabling libquadmath for gcc version 4.6.0 20110212 (experimental) [trunk
revision 170072] (GCC).

Feel free to ask for a farm account this will be much more efficient than going
through me for each test, instructions here:

http://gcc.gnu.org/wiki/CompileFarm

Building GCC on gcc70/NetBSD is simple:

PATH=/opt/cfarm/dejagnu-1.4.4/bin:$PATH
export MAKE=gmake
cd
svn co svn://gcc.gnu.org/svn/gcc/trunk
cd trunk
contrib/gcc_update
cd
mkdir build
cd build
../trunk/configure --prefix=${HOME}/install-4.6-r170072-c --disable-nls
--enable-__cxa_atexit --enable-threads=posix --with-gmp=/opt/cfarm/gmp-5.0.1
--with-mpfr=/opt/cfarm/mpfr-3.0.0 --with-mpc=/opt/cfarm/mpc-0.8.2
--enable-languages=c,fortran
gmake -j 2

[Bug c/47732] counter decremented to zero not detected when other counter overflows

[J.K.Annot.at.Infor at gmail dot com]

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

--- Comment #2 from Jan Koen Annot  
2011-02-15 14:21:16 UTC ---
(In reply to comment #1)
> And overflow is undefined in C/C++ so you are invoking undefined behavior 
> here.

Wow! This is an eye-opener for me! I am quite accustomed to assume two's
complement arithmetic with implicit wrap-around for signed integers.

After your remark I googled a bit and found several articles about undefined
behavior, e.g. John Regehr's "A Guide to Undefined Behavior in C and C++, Part
1".
Very instructive.

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

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2011-02-15 
14:24:27 UTC ---
Submitted patch: http://gcc.gnu.org/ml/fortran/2011-02/msg00135.html

[Bug libstdc++/47753] Invalid 32bit libstdc++.dll.a on mingw-w64 target

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  2011-02-15 
14:48:52 UTC ---
You say before 2011-02-13: can you figure out which specific commit did it? Do
stock 4.5.2 or 4.5.1 work for you?

[Bug c++/47752] Non-dependent name is found in dependent base class although it should be rejected

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.15 14:52:21
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-02-15 
14:52:21 UTC ---
confirmed, not a regression

I don't think this is a dup of any existing bugs relating to lookup in
dependent bases

[Bug libstdc++/47753] Invalid 32bit libstdc++.dll.a on mingw-w64 target

[dongsheng.song at gmail dot com]

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

--- Comment #2 from Dongsheng Song  2011-02-15 
14:57:13 UTC ---
(In reply to comment #1)
> You say before 2011-02-13: can you figure out which specific commit did it? Do
> stock 4.5.2 or 4.5.1 work for you?

I checkout source from gcc svn and binutils git mirror, so I said before
2011-02-13 as DATESTAMP/version.

So gcc 4.5.3 prerelease and gcc trunk before 2011-02-13 works for me.

[Bug libstdc++/47753] Invalid 32bit libstdc++.dll.a on mingw-w64 target

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2011-02-15 
15:02:57 UTC ---
Note that since 2010-12-16, when 4.5.2 has been released, only *very small*
changes went into the 4_5-branch libstdc++ code: either the problem already
existed at least *two months* earlier the date you indicated, or is a much more
general build issue not specifically related to libstdc++ details... or the
binutils you are using, I don't know.

Please provide further details.

[Bug libstdc++/47753] Invalid 32bit libstdc++.dll.a on mingw-w64 target

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2011-02-15 
15:07:48 UTC ---
I would suggest checking first what happens if you build with stock or quite a
bit older binutils. Really nothing happened to the 4_5-branch C++ runtime over
the last weeks which could explain this change.

[Bug libstdc++/47753] Invalid 32bit libstdc++.dll.a on mingw-w64 target

[dongsheng.song at gmail dot com]

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

--- Comment #5 from Dongsheng Song  2011-02-15 
15:14:27 UTC ---
(In reply to comment #3)
> Note that since 2010-12-16, when 4.5.2 has been released, only *very small*
> changes went into the 4_5-branch libstdc++ code: either the problem already
> existed at least *two months* earlier the date you indicated, or is a much 
> more
> general build issue not specifically related to libstdc++ details... or the
> binutils you are using, I don't know.
> 
> Please provide further details.

I don't know which details you want, I think it's good if someone like 
mingw-w64 folks try building themselves.

I suspect that binutils maybe the largest in charge.

[Bug fortran/47745] [OOP] Segfault with CLASS(*) and derived type dummy arguments

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org 2011-02-15 15:22:10 UTC ---
(In reply to comment #6)
> If I did not do any mistake, the patch in comment #5 breaks at least
> gfortran.dg/typebound_operator_6.f03:

Yes, I'm seeing that too. The following should take care of it:

Index: decl.c
===
--- decl.c  (revision 170170)
+++ decl.c  (working copy)
@@ -1639,7 +1639,9 @@ scalar:
   bool delayed = (gfc_state_stack->sym == c->ts.u.derived)
 || (!c->ts.u.derived->components
 && !c->ts.u.derived->attr.zero_comp);
-  return gfc_build_class_symbol (&c->ts, &c->attr, &c->as, delayed);
+  c->attr.class_ok = c->attr.dummy | c->attr.pointer |
c->attr.allocatable;
+  if (c->attr.class_ok)
+   return gfc_build_class_symbol (&c->ts, &c->attr, &c->as, delayed);
 }

   return t;


I will post a complete patch to the mailing list soon.

[Bug target/47753] Invalid 32bit libstdc++.dll.a on mingw-w64 target

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.02.15 15:29:54
  Component|libstdc++   |target
 Ever Confirmed|0   |1

--- Comment #6 from Paolo Carlini  2011-02-15 
15:29:54 UTC ---
Can you build with older binutils?

[Bug c/47690] [trans-mem] ICE in verify_cgraph_node with O0

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.02.15 15:32:33
 Ever Confirmed|0   |1

--- Comment #1 from Aldy Hernandez  2011-02-15 
15:32:33 UTC ---
Pending approval:
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00963.html

[Bug target/47753] Invalid 32bit libstdc++.dll.a on mingw-w64 target

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #7 from Kai Tietz  2011-02-15 15:34:02 
UTC ---
Yes, I assume it is a binutils issue. And my bets are going to version-script
issue. I am not 100% sure, but it looks pretty likely, as version-scripts are
used for doing export definitions.  I just sent a patch about it to binutils ML
and this issue seems to exists already for some time. I am curious that Dave
didn't noticed it earlier.
I stumbled about it by doing a binutils regression-test for 32-bit COFF
targets.

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.02.15 15:36:35
 Ever Confirmed|0   |1

--- Comment #1 from Aldy Hernandez  2011-02-15 
15:36:35 UTC ---
[I'm waiting for Richard to comment on this.  This is from an email exchange. 
Recording here, so I don't lose track.]

This rather convoluted testcase, has us jumping through hoops that eventually
inline a GIMPLE_ASM into the virtual dispose() function.

When we do our initial scan of inline asms in the diagnose_tm_blocks pass,
inlining has not run, so we don't realize dispose() will eventually contain an
inline asm.

I'm this close to just adding a sanity pass through the BBs in the final tmmark
pass.  At least the source would be readable and maintainable.

How about instead of ICEing in expand_block_tm() when encountering inline asms,
we error out.  We have all the context we need to bitch that whatever the
inliner did was not right.  Or are you sure we could've forseen this ASM ahead
of time, so the gcc_unreachable() stands as is?

[Bug target/47754] New: [missed optimization] AVX allows unaligned memory operands but GCC uses unaligned load and register operand

[kretz at kde dot org]

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

   Summary: [missed optimization] AVX allows unaligned memory
operands but GCC uses unaligned load and register
operand
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kr...@kde.org


According to the AVX docs: "With the exception of explicitly aligned 16 or 32
byte SIMD load/store instructions, most VEX-encoded, arithmetic and data
processing instructions operate in a flexible environment regarding memory
address alignment, i.e. VEX-encoded instruction with 32-byte or 16-byte load
semantics will support unaligned load operation by default. Memory arguments
for most instructions with VEX prefix operate normally without causing #GP(0)
on any byte-granularity alignment (unlike Legacy SSE instructions)."

I tested whether GCC would take advantage of this, and found that it doesn't:

_mm256_store_ps(&data[3],
  _mm256_add_ps(_mm256_load_ps(&data[0]), _mm256_load_ps(&data[1]))
);
compiles to:
vmovaps 0x200b18(%rip),%ymm0
vaddps 0x200b13(%rip),%ymm0,%ymm0
vmovaps %ymm0,0x200b10(%rip)

whereas

_mm256_store_ps(&data[3],
  _mm256_add_ps(_mm256_loadu_ps(&data[0]), _mm256_loadu_ps(&data[1]))
);
compiles to:
vmovups 0x200b4c(%rip),%ymm0
vmovups 0x200b40(%rip),%ymm1
vaddps %ymm0,%ymm1,%ymm0
vmovaps %ymm0,0x200b3c(%rip)

GCC could use a memory operand in the vaddps here instead. According to the AVX
docs, this doesn't hurt performance. But it reduces register pressure AFAIU.

Would be nice to have.

[Bug c++/47752] Non-dependent name is found in dependent base class although it should be rejected

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org

--- Comment #2 from Dodji Seketeli  2011-02-15 
15:36:59 UTC ---
I am no C++ Language Lawyer but my understanding is that G++ considers foo in
f(foo(42)) as
being type dependent. This looks somewhat related to C++ Core
Working Group issue
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1005 and I
heard that this issue is being presently discussed.

PR c++/47172 is also (remotely) related to this.

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[aldyh at gcc dot gnu.org]

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

--- Comment #2 from Aldy Hernandez  2011-02-15 
15:37:59 UTC ---
Created attachment 23351
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23351
further reduced testcase

[Bug target/47755] New: VSX code generates a TOC reference to clear memory

[meissner at gcc dot gnu.org]

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

   Summary: VSX code generates a TOC reference to clear memory
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
AssignedTo: meiss...@gcc.gnu.org
ReportedBy: meiss...@gcc.gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


If you have an array of pointers or longs in 64-bit mode that you want to
clear, via loops like when you have automatic vectorization on:

for (i = 0; i < sizeof (array) / sizeof (array[0]); i++)
  array[i] = 0;

The compiler generates the 128-bit zero constant, puts it into the constant
pool, and loads it from memory in order to set the array with vector
instructions.

Normally this would be a missed optimization, but we discovered it in compiling
_dl_start with -O3 -mcpu=power7, and at the time _dl_start is run, the TOC
registers are not yet set up, so the program crashes before it starts.

The cause of the bug is that V2DI mode is not true for either VSX_VECTOR_MODE
or ALTIVEC_VECTOR_MODE, since there are no native 64-bit operations in the VSX
or Altivec vector instructions.  This means that easy_vector_constant fails,
which in turn makes LEGITIMATE_CONSTANT_P fail.

The solution is use macros that test whether Altivec/VSX memory references can
be done, instead of macros that say we have native arithmetic support for those
modes.

[Bug target/47755] VSX code generates a TOC reference to clear memory

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  2011-02-15 
15:41:49 UTC ---
Created attachment 23352
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23352
Patch to allow V2DI easy vector constants

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

[ibolton at gcc dot gnu.org]

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

--- Comment #30 from Ian Bolton  2011-02-15 
15:47:24 UTC ---
(In reply to comment #29)
> I've had some problems with timeouts in my test setup, but I now have runs 
> that
> differ only in that pthread1.cc times out for one multilib and no longer times
> out for another. I took that as good enough to commit the patch.

Just wanted to confirm that it is working for me with 4.5 now as well.  Thanks
for all your efforts, Bernd.

[Bug c++/47704] [4.6 regression] [C++0x] Java-related error message when trying to instantiate a strongly typed enum with new

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2011-02-15 
15:48:20 UTC ---
Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165935
The problem is that ENUM_FIXED_UNDERLYING_TYPE_P and TYPE_FOR_JAVA use the same
bit.  Now that the patch changed so that it doesn't use TYPE_LANG_FLAG_2 any
longer, can't we use that for ENUM_FIXED_UNDERLYING_TYPE_P instead of
TYPE_LANG_FLAG_3 (aka TYPE_FOR_JAVA)?

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[patrick.marlier at gmail dot com]

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

--- Comment #3 from Patrick Marlier  
2011-02-15 15:59:37 UTC ---
(In reply to comment #2)
> Created attachment 23351 [details]
> further reduced testcase

Remark: In this testcase, you removed the __attribute__((transaction_pure))
which was making the asm statement legal in a transaction.

[Bug c++/47704] [4.6 regression] [C++0x] Java-related error message when trying to instantiate a strongly typed enum with new

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  2011-02-15 
16:06:39 UTC ---
Created attachment 23353
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23353
gcc46-pr47704.patch

So, either we can use TYPE_LANG_FLAG_2 here...

[Bug preprocessor/47756] New: Warning for #include " " instead of < >

[olafvdspek at gmail dot com]

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

   Summary: Warning for #include " " instead of < >
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olafvds...@gmail.com


A lot of times, #include " " is used while #include < > should be used. Could
a (optional) warning for this be added?

[Bug c++/47704] [4.6 regression] [C++0x] Java-related error message when trying to instantiate a strongly typed enum with new

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-02-15 
16:16:34 UTC ---
Created attachment 23354
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23354
gcc46-pr47704-2.patch

Or alternatively we could use TYPE_LANG_FLAG_5 here (as TYPE_LANG_FLAG_5 so far
is only used for CLASS_TYPE_P, but only on RECORD_TYPE and UNION_TYPE codes and
CLASS_TYPE_P macro checks that first).  Therefore using it for ENUMERAL_TYPE
should be fine.

BTW, unrelated to this, I wonder if we don't need to copy over that bit
in pt.c, something like:
--- pt.c 2011-02-15 15:42:18.0 +0100
+++ pt.c 2011-02-15 17:14:26.212139615 +0100
@@ -6993,6 +6993,8 @@ lookup_template_class (tree d1,
   SET_SCOPED_ENUM_P (t, SCOPED_ENUM_P (template_type));
 }
   SET_OPAQUE_ENUM_P (t, OPAQUE_ENUM_P (template_type));
+  ENUM_FIXED_UNDERLYING_TYPE_P (t)
+= ENUM_FIXED_UNDERLYING_TYPE_P (template_type);
 }
   else
 {

[Bug target/47754] [missed optimization] AVX allows unaligned memory operands but GCC uses unaligned load and register operand

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.15 16:21:49
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-02-15 
16:21:49 UTC ---
Confirmed.  Not sure if it really would not be slower for a non-load/store
instruction to need assist for unaligned loads/stores.

[Bug preprocessor/47756] Warning for #include " " instead of < >

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

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

--- Comment #1 from Andreas Schwab  2011-02-15 16:22:28 
UTC ---
How do you define these cases?

[Bug preprocessor/47756] Warning for #include " " instead of < >

[olafvdspek at gmail dot com]

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

--- Comment #2 from Olaf van der Spek  2011-02-15 
16:24:06 UTC ---
Cases where < > would work but where " " is used.

[Bug target/47754] [missed optimization] AVX allows unaligned memory operands but GCC uses unaligned load and register operand

[kretz at kde dot org]

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

--- Comment #2 from Matthias Kretz  2011-02-15 16:31:39 
UTC ---
True, the Optimization Reference Manual and AVX Docs are not very specific
about the performance impact of this. But as far as I understood the docs it
will internally not be slower than an unaligned load + op, but also not faster.
Except, of course, if it's related to memory fetch latency. So it's just about
having more registers available - again AFAIU.

If you want I can try the same testcase on ICC...

[Bug target/47754] [missed optimization] AVX allows unaligned memory operands but GCC uses unaligned load and register operand

[kretz at kde dot org]

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

--- Comment #3 from Matthias Kretz  2011-02-15 16:40:38 
UTC ---
ICC??? Whatever, I stopped to trust that compiler long ago:
:
vmovups 0x2039b8(%rip),%xmm0
vmovups 0x2039b4(%rip),%xmm1
vinsertf128 $0x1,0x2039b6(%rip),%ymm0,%ymm2
vinsertf128 $0x1,0x2039b0(%rip),%ymm1,%ymm3
vaddps %ymm3,%ymm2,%ymm4
vmovups %ymm4,0x20399c(%rip)
vzeroupper
retq

:
vmovups 0x203978(%rip),%ymm0
vaddps 0x203974(%rip),%ymm0,%ymm1
vmovups %ymm1,0x203974(%rip)
vzeroupper
retq

Nice optimization of unaligned loads there... not. ???


Just a small side-note for your enjoyment: I wrote a C++ abstraction for SSE;
and with GCC this gives an almost four-fold speedup for Mandelbrot. ICC on the
other hand compiles such awful code that - even with SSE use - it rather
creates a four-fold slowdown compared to the non-SSE code.

GCC really is a nice compiler! Keep on rocking!

[Bug middle-end/47725] [x32] error: unable to find a register to spill in class DIREG

[hjl at gcc dot gnu.org]

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

--- Comment #9 from hjl at gcc dot gnu.org  2011-02-15 
16:50:47 UTC ---
Author: hjl
Date: Tue Feb 15 16:50:43 2011
New Revision: 170179

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170179
Log:
Check zero/sign extended hard registers.

gcc/

2011-02-15  H.J. Lu  

PR middle-end/47725
* combine.c (cant_combine_insn_p): Check zero/sign extended
hard registers.

gcc/testsuite/

2011-02-15  H.J. Lu  

PR middle-end/47725
* gcc.dg/torture/pr47725.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr47725.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/43653] [4.3/4.4/4.5/4.6 Regression] ICE at reload1.c:1188 with -O1 -ftree-vectorize and empty struct

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #6 from Jeffrey A. Law  2011-02-15 17:27:44 
UTC ---
Working on trunk, still investigating if there was a patch designed to fix this
problem or if the bug has just gone latent.

[Bug target/47751] Wrong code with -mcpu=8540 -mfloat-gprs=double -mspe -Os on PowerPC

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  2011-02-15 17:51:18 UTC ---
-mfloat-gprs=double or -mspe without -mabi=spe does not correspond to any 
standard ABI variant and is very likely to be broken.

[Bug target/44218] Improve powerpc -mrecip support

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Michael Meissner  2011-02-15 
17:56:50 UTC ---
Fixed with checkin on June 3rd, 2010.

[Bug target/47636] Powerpc rs6000.md uses RS6000_RECIP_HAVE_RSQRT_P

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Michael Meissner  2011-02-15 
17:58:14 UTC ---
Fixed on February 7th, 2011.

[Bug target/47408] Several of the Altivec tests fail if run with a compiler built with --with-cpu=power7

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Michael Meissner  2011-02-15 
17:59:16 UTC ---
Fixed with checkin on January 24th, 2011.

[Bug rtl-optimization/43653] [4.3/4.4/4.5/4.6 Regression] ICE at reload1.c:1188 with -O1 -ftree-vectorize and empty struct

[ubizjak at gmail dot com]

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

--- Comment #7 from Uros Bizjak  2011-02-15 18:35:43 
UTC ---
(In reply to comment #6)
> Working on trunk, still investigating if there was a patch designed to fix 
> this
> problem or if the bug has just gone latent.

It still crashes for me (with the test from attachment 20315):

~/gcc-build/gcc/cc1 -O1 -ftree-vectorize -quiet pr43653.c 
pr43653.c: In function ‘foo’:
pr43653.c:10:1: internal compiler error: in reload, at reload1.c:1059
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


~/gcc-build/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/home/uros/gcc-build/gcc/xgcc
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/trunk/configure --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.6.0 20110214 (experimental) [trunk revision 170139] (GCC)

[Bug debug/47106] -fcompare-debug failure (length) with -fpartial-inlining -flto -fconserve-stack

[aoliva at gcc dot gnu.org]

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

--- Comment #11 from Alexandre Oliva  2011-02-15 
18:36:23 UTC ---
Author: aoliva
Date: Tue Feb 15 18:36:16 2011
New Revision: 170185

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170185
Log:
PR debug/47106
PR debug/47402
* tree-flow.h (referenced_var_lookup): Add fn parameter.
Adjust all callers.
* tree-dfa.c (referenced_var_lookup): Use fn instead of cfun.
* tree-flow-inline.h: Adjust.
* gimple-pretty-print.c: Adjust.
* tree-into-ssa.c: Adjust.
* tree-ssa.c: Adjust.
* cfgexpand.c: Adjust.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/gimple-pretty-print.c
trunk/gcc/tree-dfa.c
trunk/gcc/tree-flow-inline.h
trunk/gcc/tree-flow.h
trunk/gcc/tree-into-ssa.c
trunk/gcc/tree-ssa.c

[Bug bootstrap/47402] [4.6 Regression] Bootstrap comparison failure

[aoliva at gcc dot gnu.org]

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

--- Comment #10 from Alexandre Oliva  2011-02-15 
18:36:35 UTC ---
Author: aoliva
Date: Tue Feb 15 18:36:31 2011
New Revision: 170186

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170186
Log:
PR debug/47106
PR debug/47402
* tree-flow.h (FOR_EACH_REFERENCED_VAR): Add FN argument.
Adjust all users.  Pass FN to...
* tree-flow-inline.h (first_referenced_var): ... this.  Add
fn argument.
* ipa-struct-reorg.c: Adjust.
* tree-dfa.c: Adjust.
* tree-into-ssa.c: Adjust.
* tree-sra.c: Adjust.
* tree-ssa-alias.c: Adjust.
* tree-ssa-live.c: Adjust.
* tree-ssa.c: Adjust.
* tree-ssanames.c: Adjust.
* tree-tailcall.c: Adjust.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-struct-reorg.c
trunk/gcc/tree-dfa.c
trunk/gcc/tree-flow-inline.h
trunk/gcc/tree-flow.h
trunk/gcc/tree-into-ssa.c
trunk/gcc/tree-sra.c
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-live.c
trunk/gcc/tree-ssa.c
trunk/gcc/tree-ssanames.c
trunk/gcc/tree-tailcall.c

[Bug debug/47106] -fcompare-debug failure (length) with -fpartial-inlining -flto -fconserve-stack

[aoliva at gcc dot gnu.org]

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

--- Comment #13 from Alexandre Oliva  2011-02-15 
18:36:48 UTC ---
Author: aoliva
Date: Tue Feb 15 18:36:44 2011
New Revision: 170187

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170187
Log:
PR debug/47106
PR debug/47402
* tree-inline.h (estimated_stack_frame_size): Take cgraph node
rather than decl.
* cfgexpand.c (estimated_stack_frame_size): Likewise.
* ipa-inline.c (compute_inline_parameters): Adjust.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/ipa-inline.c
trunk/gcc/tree-inline.h

[Bug debug/47106] -fcompare-debug failure (length) with -fpartial-inlining -flto -fconserve-stack

[aoliva at gcc dot gnu.org]

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

--- Comment #12 from Alexandre Oliva  2011-02-15 
18:36:34 UTC ---
Author: aoliva
Date: Tue Feb 15 18:36:31 2011
New Revision: 170186

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170186
Log:
PR debug/47106
PR debug/47402
* tree-flow.h (FOR_EACH_REFERENCED_VAR): Add FN argument.
Adjust all users.  Pass FN to...
* tree-flow-inline.h (first_referenced_var): ... this.  Add
fn argument.
* ipa-struct-reorg.c: Adjust.
* tree-dfa.c: Adjust.
* tree-into-ssa.c: Adjust.
* tree-sra.c: Adjust.
* tree-ssa-alias.c: Adjust.
* tree-ssa-live.c: Adjust.
* tree-ssa.c: Adjust.
* tree-ssanames.c: Adjust.
* tree-tailcall.c: Adjust.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-struct-reorg.c
trunk/gcc/tree-dfa.c
trunk/gcc/tree-flow-inline.h
trunk/gcc/tree-flow.h
trunk/gcc/tree-into-ssa.c
trunk/gcc/tree-sra.c
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-live.c
trunk/gcc/tree-ssa.c
trunk/gcc/tree-ssanames.c
trunk/gcc/tree-tailcall.c

[Bug debug/47106] -fcompare-debug failure (length) with -fpartial-inlining -flto -fconserve-stack

[aoliva at gcc dot gnu.org]

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

--- Comment #14 from Alexandre Oliva  2011-02-15 
18:37:01 UTC ---
Author: aoliva
Date: Tue Feb 15 18:36:56 2011
New Revision: 170188

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170188
Log:
PR debug/47106
PR debug/47402
* cgraph.h (compute_inline_parameters): Return void.
* ipa-inline.c (compute_inline_parameters): Adjust.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.h
trunk/gcc/ipa-inline.c

[Bug bootstrap/47402] [4.6 Regression] Bootstrap comparison failure

[aoliva at gcc dot gnu.org]

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

--- Comment #9 from Alexandre Oliva  2011-02-15 
18:36:21 UTC ---
Author: aoliva
Date: Tue Feb 15 18:36:16 2011
New Revision: 170185

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170185
Log:
PR debug/47106
PR debug/47402
* tree-flow.h (referenced_var_lookup): Add fn parameter.
Adjust all callers.
* tree-dfa.c (referenced_var_lookup): Use fn instead of cfun.
* tree-flow-inline.h: Adjust.
* gimple-pretty-print.c: Adjust.
* tree-into-ssa.c: Adjust.
* tree-ssa.c: Adjust.
* cfgexpand.c: Adjust.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/gimple-pretty-print.c
trunk/gcc/tree-dfa.c
trunk/gcc/tree-flow-inline.h
trunk/gcc/tree-flow.h
trunk/gcc/tree-into-ssa.c
trunk/gcc/tree-ssa.c

[Bug bootstrap/47402] [4.6 Regression] Bootstrap comparison failure

[aoliva at gcc dot gnu.org]

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

--- Comment #12 from Alexandre Oliva  2011-02-15 
18:37:01 UTC ---
Author: aoliva
Date: Tue Feb 15 18:36:56 2011
New Revision: 170188

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170188
Log:
PR debug/47106
PR debug/47402
* cgraph.h (compute_inline_parameters): Return void.
* ipa-inline.c (compute_inline_parameters): Adjust.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.h
trunk/gcc/ipa-inline.c

[Bug bootstrap/47402] [4.6 Regression] Bootstrap comparison failure

[aoliva at gcc dot gnu.org]

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

--- Comment #11 from Alexandre Oliva  2011-02-15 
18:36:48 UTC ---
Author: aoliva
Date: Tue Feb 15 18:36:44 2011
New Revision: 170187

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170187
Log:
PR debug/47106
PR debug/47402
* tree-inline.h (estimated_stack_frame_size): Take cgraph node
rather than decl.
* cfgexpand.c (estimated_stack_frame_size): Likewise.
* ipa-inline.c (compute_inline_parameters): Adjust.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/ipa-inline.c
trunk/gcc/tree-inline.h

[Bug target/47755] VSX code generates a TOC reference to clear memory

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  2011-02-15 
18:43:01 UTC ---
Author: meissner
Date: Tue Feb 15 18:42:59 2011
New Revision: 170189

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170189
Log:
Fix PR 47755

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr47755.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug target/47755] VSX code generates a TOC reference to clear memory

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Michael Meissner  2011-02-15 
18:44:19 UTC ---
Fixed in subversion checkin #170189.

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

[hubicka at ucw dot cz]

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

--- Comment #13 from Jan Hubicka  2011-02-15 18:49:15 
UTC ---
> A quick summary to see if got this right:

Yes, the summary seems right.

Note that GCC plays now games with not putting COMDATs into LTO symbol table
unless they really need to be unique.  So if you have simple inline functions
with no address taken things the function is never put into LTO symbol table
and linker doesn't care. GCC then merge the different copies itself and promote
the function into static function.  This worlsf well except for possibility of
having two instances of the function (one in LTO world that is promoted to
static function and one in non-LTO code staying as comdat).
This works well for Firefox ;))

Things gets ugly with variables and stuff that has address taken. This is less
common in C++ code but still worrysome.

> On LLVM land I think this translates to
> 
> *) If given PREVAILING_DEF, linkonce gets upgrade to weak and linkonce_odr to
> weak_odr
> *) If given PREVAILING_DEF_IRONLY_EXP, likages stay as they are
> *) If given PREVAILING_DEF_IRONLY the symbol gets internalized
> 
> I think this should work, thanks.

I am not sure if you are allowed to change COMDAT into weak. The plugin spec
explicitely speaks of comdat symbol staying and I am not sure if Gold/GNU ld
are ready for symbol changing their type. 

Taking PREVAILING_DEF is silently accepted by both gold and GNU ld, but in gold
it results in stale dynamic symbol table entries.  GCC originally behaved on
PREVAILING_DEF as if it was PREVAILING_DEF_IRONLY_EXP and it did result in
massive dynamic symbol table section increases.

Honza

[Bug target/47755] VSX code generates a TOC reference to clear memory

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  2011-02-15 
18:51:18 UTC ---
Author: meissner
Date: Tue Feb 15 18:51:15 2011
New Revision: 170190

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170190
Log:
Fix PR 47755

Added:
branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.target/powerpc/pr47755.c
  - copied unchanged from r170189,
trunk/gcc/testsuite/gcc.target/powerpc/pr47755.c
Modified:
branches/ibm/gcc-4_5-branch/gcc/config/rs6000/predicates.md

[Bug target/47755] VSX code generates a TOC reference to clear memory

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  2011-02-15 
18:51:39 UTC ---
Author: meissner
Date: Tue Feb 15 18:51:35 2011
New Revision: 170191

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170191
Log:
Fix PR 47755

Modified:
branches/ibm/gcc-4_5-branch/gcc/ChangeLog.ibm
branches/ibm/gcc-4_5-branch/gcc/testsuite/ChangeLog.ibm

[Bug rtl-optimization/43653] [4.3/4.4/4.5/4.6 Regression] ICE at reload1.c:1188 with -O1 -ftree-vectorize and empty struct

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  2011-02-15 19:01:20 
UTC ---
ah.  Fails with -O1 -ftree-vectorize, works with -O2 -ftree-vectorize on trunk.

Appears that we allocate memory (via get_secondary_mem) after the point at
which we believe the size of frame should be fixed.  This would tend to
indicate that during find_reloads we thought no secondary memory was needed,
but then later decided it was needed.  That's clearly bad.

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

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #11 from Uros Bizjak  2011-02-15 19:21:13 
UTC ---
As seen in [1], still fails on ia64-hp-hpux11.23.

The bug can be triggered with a crosscompiler to the above target:

~/gcc-build-xxx/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/home/uros/gcc-build-xxx/gcc/xgcc
Target: ia64-hp-hpux11.23
Configured with: ../gcc-svn/trunk/configure --target=ia64-hp-hpux11.23
--enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20110215 (experimental) [trunk revision 170189] (GCC) 

~/gcc-build-xxx/gcc/cc1plus -O2 -gdwarf-2 -quiet -milp32 pr47283.C 
pr47283.C: In member function ‘virtual void E::f10()’:
pr47283.C:58:1: internal compiler error: in refs_may_alias_p_1, at
tree-ssa-alias.c:1083
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[1] http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg01661.html

[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #7 from Richard Henderson  2011-02-15 
19:36:28 UTC ---
(In reply to comment #6)
> The reason for ICE is that POST_DEC is not handled in
> dwarf2out_frame_debug_expr(). Fixing that issue will enable the compiler to
> generate the call-stack debug info.

This is handled by properly defining INCOMING_FRAME_SP_OFFSET.
You don't need a POST_DEC in the INCOMING_RETURN_ADDR_RTX definition.

C.f. the i386 versions of these, which set up the exact same sort of
on-stack return address.

[Bug fortran/47633] Result of COMPILER_VERSION() has NULL byte appended

[kargl at gcc dot gnu.org]

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

--- Comment #10 from kargl at gcc dot gnu.org 2011-02-15 19:38:54 UTC ---
Author: kargl
Date: Tue Feb 15 19:38:51 2011
New Revision: 170195

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170195
Log:
2011-02-15  Steven G. Kargl  

PR fortran/47633
. simplify.c (gfc_simplify_compiler_version): Fix off-by-one issue.

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

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

[rafael.espindola at gmail dot com]

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

--- Comment #14 from Rafael Avila de Espindola  2011-02-15 19:39:09 UTC ---
Sorry, can you expand on what gcc was doing that was causing it to expand the
dynamic symbol table?

With LLVM what we are doing is

*) Report all symbols
*) Any symbol not given a PREVAILING_DEF, we make it internal.
*) All other symbols stay the same.

For example, a vtable is normally produce as a symbol with linkonce_odr (see
http://llvm.org/docs/LangRef.html#linkage_linkonce_odr). If it is not used, we
drop it.

The potential problem with what LLVM is doing (I don't have a seem it in
practice, but haven't tried to force it) is the case

* file a.cc has the vtable for class foo and a use of it
* file b.cc has the vtable for class foo and a use of it

We produce IL for a.cc and a ELF for b.cc. Gold decides to use the IL version,
gives the plugin a PREVAILING_DEF. LLVM optimises the use away and drops the
vtable. We now have an undefined reference to the vtable.

With both PREVAILING_DEF_IRONLY_EXP and PREVAILING_DEF llvm would be able to
tell the difference. If there was no use of the vtable from an ELF file, gold
would give a PREVAILING_DEF_IRONLY_EXP and llvm would be allowed to drop it. If
there is, gold gives a PREVAILING_DEF and llvm must upgrade the vtable from
linkonce_odr to weak_odr which causes it to say in the final .o even if it
optimises out all uses.

[Bug fortran/47633] Result of COMPILER_VERSION() has NULL byte appended

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from kargl at gcc dot gnu.org 2011-02-15 19:44:44 UTC ---
Fixed on trunk.  Closing.

[Bug middle-end/47725] [x32] error: unable to find a register to spill in class DIREG

[hjl at gcc dot gnu.org]

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

--- Comment #10 from hjl at gcc dot gnu.org  2011-02-15 
19:46:29 UTC ---
Author: hjl
Date: Tue Feb 15 19:46:26 2011
New Revision: 170197

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170197
Log:
Revert cant_combine_insn_p change.

gcc/

2011-02-15  H.J. Lu  

PR middle-end/47725
* combine.c (cant_combine_insn_p): Revert the last change.

gcc/testsuite/

2011-02-15  H.J. Lu  

PR middle-end/47725
* gcc.dg/torture/pr47725.c: Removed.

Removed:
trunk/gcc/testsuite/gcc.dg/torture/pr47725.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/47757] New: Unintentionally? not exported _gfortran_* symbols in libgfortran.so.3

[jakub at gcc dot gnu.org]

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

   Summary: Unintentionally? not exported _gfortran_* symbols in
libgfortran.so.3
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


On x86_64-linux
readelf -Ws libgfortran.so.3 | grep LOCAL.*_gfortran | grep -v _gfortrani | awk
'{print $8}' | sort -u
command gives:
_gfortran_cshift0_16_char4
_gfortran_eoshift0_16_char4
_gfortran_eoshift2_16_char4
_gfortran_miall_i1
_gfortran_miall_i16
_gfortran_miall_i2
_gfortran_miall_i4
_gfortran_miall_i8
_gfortran_miany_i1
_gfortran_miany_i16
_gfortran_miany_i2
_gfortran_miany_i4
_gfortran_miany_i8
_gfortran_miparity_i1
_gfortran_miparity_i16
_gfortran_miparity_i2
_gfortran_miparity_i4
_gfortran_miparity_i8
_gfortran_siall_i1
_gfortran_siall_i16
_gfortran_siall_i2
_gfortran_siall_i4
_gfortran_siall_i8
_gfortran_siany_i1
_gfortran_siany_i16
_gfortran_siany_i2
_gfortran_siany_i4
_gfortran_siany_i8
_gfortran_siparity_i1
_gfortran_siparity_i16
_gfortran_siparity_i2
_gfortran_siparity_i4
_gfortran_siparity_i8

are they not exported from libgfortran.so.3 intentionally or is it just an
omission in gfortran.map?  For *iall*/*iany*/*iparity* it seems they non-s/m
variant has been added recently, so maybe just an omission, for the *char4
symbols I have no idea.

[Bug libgomp/47758] New: 729 unexpected failures in the libgomp test suite on powerpc-apple-darwin8

[dominiq at lps dot ens.fr]

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

   Summary: 729 unexpected failures in the libgomp test suite on
powerpc-apple-darwin8
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: ja...@redhat.com, bur...@net-b.de, ia...@gcc.gnu.org
  Host: powerpc-apple-darwin8
Target: powerpc-apple-darwin8
 Build: powerpc-apple-darwin8


I ventured in building gcc 4.6.0 (trunk revision 170169) on
powerpc-apple-darwin8 configured with:

../work/configure --prefix=/opt/gcc/gcc4.6w --target=powerpc-apple-darwin8
--host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8
--enable-languages=c,c++,fortran,lto --with-gmp=/sw --with-libiconv-prefix=/sw
--with-system-zlib --enable-checking=release --with-dwarf2 --disable-multilib
--disable-libquadmath --disable-libquadmath-support

and I got a high number of failures in libgomp.fortran:

=== libgomp Summary ===

# of expected passes1793
# of unexpected failures729
# of unsupported tests2

FAIL: libgomp.fortran/allocatable1.f90  -O0  (test for excess errors)
FAIL: libgomp.fortran/allocatable1.f90  -O1  (test for excess errors)
FAIL: libgomp.fortran/allocatable1.f90  -O2  (test for excess errors)
FAIL: libgomp.fortran/allocatable1.f90  -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: libgomp.fortran/allocatable1.f90  -O3 -fomit-frame-pointer -funroll-loops
 (test for excess errors)
FAIL: libgomp.fortran/allocatable1.f90  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
FAIL: libgomp.fortran/allocatable1.f90  -O3 -g  (test for excess errors)
FAIL: libgomp.fortran/allocatable1.f90  -Os  (test for excess errors)
...

Most (if not all) are of the following kind:

/libgomp/testsuite/.. -shared-libgcc -fmessage-length=0 -fopenmp
-B/opt/gcc/build/powerpc-apple-darwin8/./libgomp/../libquadmath/.libs/  -O0  
-B/opt/gcc/build/powerpc-apple-darwin8/./libgomp/../libgfortran/.libs  
-L/opt/gcc/build/powerpc-apple-darwin8/./libgomp/.libs -lgomp
-L/opt/gcc/build/powerpc-apple-darwin8/./libgomp/../libquadmath/.libs/
-L/opt/gcc/build/powerpc-apple-darwin8/./libgomp/../libgfortran/.libs
-lgfortran -lm   -o ./allocatable1.exe(timeout = 300)
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning -L: directory name
(/opt/gcc/build/powerpc-apple-darwin8/./libgomp/../libquadmath/.libs/) does not
exist

I have tested different variants around the options  --disable-libquadmath
--disable-libquadmath-support without change. Note that with these two options
no libquadmath is build while I don't need them on powerpc-apple-darwin9 (so I
see powerpc-apple-darwin9/libquadmath, but no
powerpc-apple-darwin9/libquadmath/.libs and the libgomp tests pass without
failures).

[Bug rtl-optimization/43653] [4.3/4.4/4.5/4.6 Regression] ICE at reload1.c:1188 with -O1 -ftree-vectorize and empty struct

[law at redhat dot com]

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

--- Comment #9 from Jeffrey A. Law  2011-02-15 21:06:23 
UTC ---
I think an x86 maintainer is going to need to take a look at this.

The problem as I see it is we're trying to use the address of a stack slot as a
vector initializer.  

(insn 20 17 21 2 (set (reg:V2DI 74 [ vect_cst_.2 ])
(vec_duplicate:V2DI (reg/f:DI 20 frame))) j.c:4 1788 {*vec_dupv2di}
 (expr_list:REG_EQUIV (vec_duplicate:V2DI (reg/f:DI 20 frame))
(nil)))

There's nothing inherently wrong with that.  Eventually frame gets turned into
sp+offset like this:

(insn 20 17 21 2 (set (reg:V2DI 21 xmm0 [orig:74 vect_cst_.2 ] [74])
(vec_duplicate:V2DI (plus:DI (reg/f:DI 7 sp)
(const_int 392 [0x188] j.c:4 1788 {*vec_dupv2di}
 (expr_list:REG_EQUIV (vec_duplicate:V2DI (plus:DI (reg/f:DI 7 sp)
(const_int 392 [0x188])))
(nil)))

This is a natural result of FP elimination and IMHO, we're still OK. That later
gets turned into:

(insn 20 17 21 2 (set (reg:V2DI 21 xmm0 [orig:74 vect_cst_.2 ] [74])
(vec_duplicate:V2DI (plus:DI (reg/f:DI 7 sp)
(mem/u/c/i:DI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S8
A64] j.c:4 1788 {*vec_dupv2di}
 (expr_list:REG_EQUIV (vec_duplicate:V2DI (plus:DI (reg/f:DI 7 sp)
(const_int 392 [0x188])))
(nil)))

Dubious, but I understand why the code did this.We'll have the following
reload recorded:

Reload 0: reload_in (DI) = (plus:DI (reg/f:DI 7 sp)
(mem/u/c/i:DI
(symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S8 A64]))
reload_out (V2DI) = (reg:V2DI 21 xmm0 [orig:74 vect_cst_.2 ] [74])
SSE_REGS, RELOAD_OTHER (opnum = 0), can't combine
reload_in_reg: (plus:DI (reg/f:DI 7 sp)
(const_int 392 [0x188]))
reload_out_reg: (reg:V2DI 21 xmm0 [orig:74 vect_cst_.2 ] [74])
reload_reg_rtx: (reg:V2DI 22 xmm1)

Which simply isn't going to work and it's all downhill from there, including a
surprise secondary memory allocation which ultimately triggers the ICE.

I was able to hack things to work by enabling a secondary reload when copying
(plus (sp) (whatever)) into SSE_REGS, but that may not be the best solution. 
Someone with more x86 internal knowledge should look at this.

[Bug bootstrap/45381] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: error: AltiVec argument passed to unprototyped function

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres  
2011-02-15 21:06:59 UTC ---
Note that I did not have any problem to compile libcpp/lex.c on
powerpc-apple-darwin8 with
gcc version 4.0.1 (Apple Computer, Inc. build 5370):

...
gcc  -I../../work/libcpp -I. -I../../work/libcpp/../include
-I../../work/libcpp/include -I/sw/include -g -fkeep-inline-functions -W -Wall
-Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -pedantic -Wno-long-long 
-I../../work/libcpp -I. -I../../work/libcpp/../include
-I../../work/libcpp/include -I/sw/include -c -o lex.o -MT lex.o -MMD -MP -MF
.deps/lex.Tpo ../../work/libcpp/lex.c
...
/opt/gcc/build/./prev-gcc/xgcc -B/opt/gcc/build/./prev-gcc/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin8/bin/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin8/bin/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin8/lib/ -isystem
/opt/gcc/gcc4.6w/powerpc-apple-darwin8/include -isystem
/opt/gcc/gcc4.6w/powerpc-apple-darwin8/sys-include -I../../work/libcpp -I.
-I../../work/libcpp/../include -I../../work/libcpp/include -I/sw/include -g -O2
-mdynamic-no-pic -gtoggle -W -Wall -Wwrite-strings -Wmissing-format-attribute
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat
-pedantic -Wno-long-long -Werror -I../../work/libcpp -I.
-I../../work/libcpp/../include -I../../work/libcpp/include -I/sw/include -c -o
lex.o -MT lex.o -MMD -MP -MF .deps/lex.Tpo ../../work/libcpp/lex.c

[Bug rtl-optimization/37273] [4.4/4.5/4.6 Regression] IRA does not re-materializes addresses (loads from the TOC)

[law at gcc dot gnu.org]

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

--- Comment #12 from Jeffrey A. Law  2011-02-15 
21:22:03 UTC ---
Author: law
Date: Tue Feb 15 21:21:59 2011
New Revision: 170199

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

Revert
2011-01-25  Jeff Law  

PR rtl-optimization/37273
* ira-costs.c (scan_one_insn): Detect constants living in memory and
handle them like argument loads from stack slots.  Do not double
count memory for memory constants and argument loads from stack slots.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-costs.c

[Bug rtl-optimization/37273] [4.4/4.5/4.6 Regression] IRA does not re-materializes addresses (loads from the TOC)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Blocks||46542
 Resolution|FIXED   |
   Target Milestone|4.6.0   |4.7.0

--- Comment #13 from Jeffrey A. Law  2011-02-15 21:24:13 
UTC ---
Patch reverted due to exposing several latent bugs.  Bugfixes for the latent
issues have been kept.  Patch queued for gcc-4.7.  Prior to installing for
gcc-4.7 sparc-rtems needs testing.

[Bug fortran/47648] libgfortran/libgfortran.h:53:29: fatal error: quadmath_weak.h: No such f ile or directory - FreeBSD ia64

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2011-02-15 
21:30:46 UTC ---
Author: burnus
Date: Tue Feb 15 21:30:43 2011
New Revision: 170200

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170200
Log:
2011-02-15  Tobias Burnus  

PR fortran/47716
PR fortran/47648
* acinclude.m4 (LIBGFOR_CHECK_FLOAT128): Use check from
libquadmath, which uses more features.
* configure: Regenerate.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/acinclude.m4
trunk/libgfortran/configure

[Bug libfortran/47716] libgfortran quadmath_weak.h not found on NetBSD 5.1

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2011-02-15 
21:30:45 UTC ---
Author: burnus
Date: Tue Feb 15 21:30:43 2011
New Revision: 170200

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170200
Log:
2011-02-15  Tobias Burnus  

PR fortran/47716
PR fortran/47648
* acinclude.m4 (LIBGFOR_CHECK_FLOAT128): Use check from
libquadmath, which uses more features.
* configure: Regenerate.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/acinclude.m4
trunk/libgfortran/configure

[Bug c/46620] 32-bit structures containing bitfields are not copied correctly on -O2 , x86 backend

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #4 from Alexandre Oliva  2011-02-15 
21:51:26 UTC ---
Mine