[Bug tree-optimization/33512] Simple bitwise simplification missed

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  2012-04-24 
07:05:15 UTC ---
Author: pinskia
Date: Tue Apr 24 07:05:09 2012
New Revision: 186749

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

2012-04-24  Andrew Pinski  

PR tree-opt/33512
* tree-ssa-forwprop.c (defcodefor_name): New function.
(simplify_bitwise_binary): Use defcodefor_name instead of manually
Simplify "( X | Y) & X" to X and "( X & Y) | X" to X.
Simplify "(~X | Y) & X" to "X & Y" and
"(~X & Y) | X" to "X | Y".

2012-04-24  Andrew Pinski  

PR tree-opt/33512
* gcc.dg/tree-ssa/andor-3.c: New testcase.
* gcc.dg/tree-ssa/andor-4.c: New testcase.
* gcc.dg/tree-ssa/andor-5.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/andor-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/andor-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/andor-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug tree-optimization/33512] Simple bitwise simplification missed

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  2012-04-24 
07:05:48 UTC ---
Fixed.

[Bug middle-end/53100] New: Optimize __int128 with range information

[marc.glisse at normalesup dot org]

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

 Bug #: 53100
   Summary: Optimize __int128 with range information
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org


(not sure about the "component" field)

In the following program, on x86_64, the first version generates two imulq,
while the second generates 4 imulq and 2 mulq. It would be convenient if I
could just write the whole code with __int128 and let the compiler do the
optimization by tracking the range of numbers.

int f(int a,int b,int c,int d,int e,int f){
#if 0
  long x=a;
  long y=b;
  long z=c;
  long t=d;
  long u=e;
  long v=f;
  return (z-x)*(__int128)(v-y) < (u-x)*(__int128)(t-y);
#else
  __int128 x=a;
  __int128 y=b;
  __int128 z=c;
  __int128 t=d;
  __int128 u=e;
  __int128 v=f;
  return (z-x)*(v-y) < (u-x)*(t-y);
#endif
}

[Bug middle-end/53010] [4.8 Regression] crash due to null ptr deref

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Andrew Pinski  2012-04-24 
07:08:36 UTC ---
Fixed so closing as such.  It was most likely one of the loop fixes that fixed
this bug.

[Bug target/53033] [avr]: Wrong register number for 3-byte loads via X

[mhlavink at redhat dot com]

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

--- Comment #6 from Michal Hlavinka  2012-04-24 
07:26:37 UTC ---
(In reply to comment #5)
> Fixed in 4.7.1

verified
Thanks

[Bug tree-optimization/33512] Simple bitwise simplification missed

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ktietz at gcc dot gnu.org
 Resolution|FIXED   |

--- Comment #12 from Kai Tietz  2012-04-24 07:38:25 
UTC ---
Cause bootstrap failure

./../gcc/gcc/tree-ssa-ifcombine.c -o tree-ssa-ifcombine.o
../../gcc/gcc/tree-ssa-forwprop.c: In function `simplify_bitwise_binary':
../../gcc/gcc/tree-ssa-forwprop.c:1916: error: `def1' undeclared (first use in
this function)
../../gcc/gcc/tree-ssa-forwprop.c:1916: error: (Each undeclared identifier is
reported only once
../../gcc/gcc/tree-ssa-forwprop.c:1916: error: for each function it appears
in.)

../../gcc/gcc/tree-ssa-forwprop.c:1917: error: `def2' undeclared (first use in
this function)

[Bug fortran/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Component|middle-end  |fortran

--- Comment #6 from Richard Guenther  2012-04-24 
07:57:43 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > 
> > From F2003 standard one finds on page 99:
> > 
> >The form variable-name (explicit-shape-spec-list) declares variable-name
> >to have the DIMENSION attribute and specifies the array properties that
> >apply.
> > 
> > My interpretation is that
> > 
> >   COMMON /FMCOM / X(1)
> > 
> > declares X to have 1 element while
> > 
> >   PARAMETER (MEMSIZ=   80 000 000)
> >   COMMON /FMCOM / X(MEMSIZ)
> > 
> > has 8000 elements.  The above appears to be a common
> > F77 idiom for "dynamic" memory management where the 
> > programmer is abusing the storage association of element
> > x(1).
> 
> I was told that it was allowed in F77.

If it is allowed in F77 then the GFortran frontend needs to be fixed.  First,
-fbounds-check may not fail, second, the array type in the COMMON aggregate
type shall not have a defined size (instead it would come from the COMMONs
DECL_SIZE).

Thus, this is a frontend bug which is pre-existing with -fbounds-check
and in 4.8 triggers wrong-code generation.

[Bug tree-optimization/53098] [4.8 Regression] tree-vect-loop.c:1414:19: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Guenther  2012-04-24 
08:06:31 UTC ---
Bah.  Fixed.

[Bug tree-optimization/53098] [4.8 Regression] tree-vect-loop.c:1414:19: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-04-24 
08:06:33 UTC ---
Author: rguenth
Date: Tue Apr 24 08:06:20 2012
New Revision: 186754

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186754
Log:
2012-04-24  Richard Guenther  

PR tree-optimization/53098
* tree-vect-loop.c (vect_analyze_loop_operations): Fixup
comparison sign.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug c/53095] std=gnu99 atof x86

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #4 from Richard Guenther  2012-04-24 
08:08:06 UTC ---
.

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

[Bug tree-optimization/53092] ICE using -ftree-loop-if-convert-stores -O3

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-04-24
  Component|other   |tree-optimization
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-04-24 
08:10:48 UTC ---
Works for me.  Can you try an updated compiler?

[Bug middle-end/53089] [4.8 Regression] gfortran.dg/coarray/atomic_1.f90 and gfortran.dg/coarray/registering_1.f90

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug middle-end/323] optimized code gives strange floating point results

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||JoaquinMonleon at gmail dot
   ||com

--- Comment #184 from Richard Guenther  2012-04-24 
08:08:06 UTC ---
*** Bug 53095 has been marked as a duplicate of this bug. ***

[Bug middle-end/53088] [4.8 Regression] gcc.target/i386/pr39082-1.c

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |hubicka at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.8.0

[Bug tree-optimization/33512] Simple bitwise simplification missed

[pinskia at gcc dot gnu.org]

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

--- Comment #13 from Andrew Pinski  2012-04-24 
08:19:59 UTC ---
Patch which I am testing:
Index: tree-ssa-forwprop.c
===
--- tree-ssa-forwprop.c(revision 186755)
+++ tree-ssa-forwprop.c(working copy)
@@ -1913,10 +1913,10 @@ simplify_bitwise_binary (gimple_stmt_ite
/* Simplify (A & B) OP0 (C & B) to (A OP0 C) & B. */
if (def1_code == def2_code
&& def1_code == BIT_AND_EXPR
-   && operand_equal_for_phi_arg_p (gimple_assign_rhs2 (def1),
-   gimple_assign_rhs2 (def2)))
+   && operand_equal_for_phi_arg_p (def1_arg2,
+   def2_arg2))
 {
-  tree b = gimple_assign_rhs2 (def1);
+  tree b = def1_arg2;
   tree a = def1_arg1;
   tree c = def2_arg1;
   tree inner = fold_build2 (code, TREE_TYPE (arg2), a, c);

--- CUT ---
This was definitely my fault.  I tested both patches independently and forgot
to test them together.  Sorry about that.

[Bug tree-optimization/33512] Simple bitwise simplification missed

[ktietz at gcc dot gnu.org]

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

--- Comment #14 from Kai Tietz  2012-04-24 08:30:49 
UTC ---
Hmm, I have right now in my tree

Index: tree-ssa-forwprop.c
===
--- tree-ssa-forwprop.c (revision 186753)
+++ tree-ssa-forwprop.c (working copy)
@@ -1912,17 +1912,25 @@

/* Simplify (A & B) OP0 (C & B) to (A OP0 C) & B. */
if (def1_code == def2_code
-   && def1_code == BIT_AND_EXPR
-   && operand_equal_for_phi_arg_p (gimple_assign_rhs2 (def1),
-  gimple_assign_rhs2 (def2)))
+   && def1_code == BIT_AND_EXPR)
 {
-  tree b = gimple_assign_rhs2 (def1);
-  tree a = def1_arg1;
-  tree c = def2_arg1;
-  tree inner = fold_build2 (code, TREE_TYPE (arg2), a, c);
+  tree inner, a = NULL_TREE, b = NULL_TREE, c = NULL_TREE;
+
+  if (operand_equal_for_phi_arg_p (def1_arg2, def2_arg2))
+   { b = def1_arg2; a = def1_arg1; c = def2_arg1; }
+  else if (operand_equal_for_phi_arg_p (def1_arg1, def2_arg1))
+   { b = def1_arg1; a = def1_arg2; c = def2_arg2; }
+  else if (operand_equal_for_phi_arg_p (def1_arg1, def2_arg2))
+   { b = def1_arg1; a = def1_arg2; c = def2_arg1; }
+  else if (operand_equal_for_phi_arg_p (def1_arg2, def2_arg1))
+   { b = def1_arg2; a = def1_arg1; c = def2_arg2; }
+  if (a && c)
+   inner = fold_build2 (code, TREE_TYPE (arg2), a, c);
+  if (!a || !b || !c)
+   ;
   /* If A OP0 C (this usually means C is the same as A) is 0
 then fold it down correctly. */
-  if (integer_zerop (inner))
+  else if (integer_zerop (inner))
{
  gimple_assign_set_rhs_from_tree (gsi, inner);
  update_stmt (stmt);

It has the advantage of handling also cases for (A & B) OP0 (C & B) to (A OP0
C) & B, (B & A) OP0 (C & B) to (A OP0 C) & B, (A & B) OP0 (B & C) to (A OP0 C)
& B, and (B & A) OP0 (B & C) to (A OP0 C) & B.

It bootstraps fine.

[Bug c++/53078] [C++11] Wrong diagnostic "no return statement in function returning non-void" on lambdas

[mattipee at yahoo dot co.uk]

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

mattipee at yahoo dot co.uk changed:

   What|Removed |Added

 CC||mattipee at yahoo dot co.uk

--- Comment #4 from mattipee at yahoo dot co.uk 2012-04-24 08:34:17 UTC ---
Duplicate of Bug 52845

[Bug tree-optimization/33512] Simple bitwise simplification missed

[pinskia at gcc dot gnu.org]

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

--- Comment #15 from Andrew Pinski  2012-04-24 
08:37:52 UTC ---
>Hmm, I have right now in my tree

The most common case is with b being a constant which is why I only looked into
that case.

[Bug fortran/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  2012-04-24 
08:38:43 UTC ---
Found the discussion:
http://gcc.gnu.org/ml/fortran/2011-05/msg00079.html

[Bug translation/52984] Different information message in Turkish locale.

[yasar11732 at gmail dot com]

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

--- Comment #2 from Yaşar Arabacı  2012-04-24 
08:43:29 UTC ---
(In reply to comment #1)
> The translations are handled by the translation project.  Translation issues
> should be reported directly to them rather to us.

Do you mean this: http://translationproject.org/html/welcome.html ? I searched
for a bit but I don't see no place for a bug report.

[Bug middle-end/31094] Support annotating function parameters as read-only and/or non-escaping

[slayoo at staszic dot waw.pl]

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

Sylwester Arabas  changed:

   What|Removed |Added

 CC||slayoo at staszic dot
   ||waw.pl

--- Comment #6 from Sylwester Arabas  2012-04-24 
08:50:52 UTC ---
Perhaps that's somehow related to the issue described in this message:
http://gcc.gnu.org/ml/fortran/2012-04/msg00122.html
Sylwester

[Bug c++/25973] [4.5/4.6/4.7/4.8 Regression] Wrong warning: control reaches end of non-void function

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #19 from vries at gcc dot gnu.org 2012-04-24 08:52:03 UTC ---
Problem in comment 4 fixed in 4.8: r186546.

Un-assigning myself for problem in description field.

[Bug tree-optimization/33512] Simple bitwise simplification missed

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #16 from Andrew Pinski  2012-04-24 
08:56:43 UTC ---
Fixed the bootstrap issue now so closing as fixed.

[Bug fortran/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  2012-04-24 
09:14:57 UTC ---
http://gcc.gnu.org/ml/gcc-bugs/2003-09/msg02301.html

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |jb at gcc dot gnu.org
   |gnu.org |

--- Comment #3 from Janne Blomqvist  2012-04-24 09:17:02 
UTC ---
Created attachment 27228
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27228
Proposed untested patch

The attached patch should fix this, although I haven't tested it yet.

[Bug fortran/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  2012-04-24 
09:17:23 UTC ---
I think http://gcc.gnu.org/ml/fortran/2006-07/msg00307.html is also referencing
it too.

[Bug c++/53078] [C++11] Wrong diagnostic "no return statement in function returning non-void" on lambdas

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2012-04-24
 CC||paolo.carlini at oracle dot
   ||com
 Resolution|WORKSFORME  |
 Ever Confirmed|0   |1

--- Comment #5 from Paolo Carlini  2012-04-24 
09:28:33 UTC ---
Re-open..

[Bug c++/52845] non-void return type deduced for lambda with empty compound statement

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||M8R-gt1qwe at mailinator
   ||dot com

--- Comment #4 from Paolo Carlini  2012-04-24 
09:29:09 UTC ---
*** Bug 53078 has been marked as a duplicate of this bug. ***

[Bug fortran/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther  2012-04-24 
09:29:10 UTC ---
A "fix" would be for example

Index: gcc/expr.c
===
--- gcc/expr.c  (revision 186757)
+++ gcc/expr.c  (working copy)
@@ -6809,7 +6809,8 @@ array_at_struct_end_p (tree ref)

   /* If the reference is based on a declared entity, the size of the array
  is constrained by its given domain.  */
-  if (DECL_P (ref))
+  if (DECL_P (ref)
+  && !DECL_COMMON (ref))
 return false;

   return true;

of course other parts of the compiler will still be affected by this.
If the Frontend wants to reliably make this work then it has to use
an open-ended TYPE_DOMAIN for the array (and then lay out the underlying
decl manually).  Not sure if that's easy though (the incomplete type might
trigger ICEs in other places).

[Bug c++/53078] [C++11] Wrong diagnostic "no return statement in function returning non-void" on lambdas

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||DUPLICATE

--- Comment #6 from Paolo Carlini  2012-04-24 
09:29:09 UTC ---
... to close as duplicate.

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

[Bug middle-end/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2012-04-24 
09:35:53 UTC ---
(In reply to comment #6)
> This occurs in default_elf_select_section.  For example,
You are looking at wrong spot.

What happens on this testcase is 
default_elf_select_rtx_section and the PA specific part of that is just that PA
needs any constants that need relocations pushed into the constant pool, other
targets don't.

[Bug middle-end/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Jakub Jelinek  2012-04-24 
09:40:17 UTC ---
Should be fixed now.

[Bug c++/25973] [4.5/4.6/4.7/4.8 Regression] Wrong warning: control reaches end of non-void function

[ssomers at opnet dot com]

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

ssomers at opnet dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #20 from ssomers at opnet dot com 2012-04-24 09:57:33 UTC ---
I concur with comment 11 that the original problem doesn't occur anymore in
4.4.4 (it still occurred in 4.1.2). Since the variation in comment 4 was also
patched, and being unaware about the protocol, I'll go out on a limp and try to
close this.

[Bug target/53101] New: Recognize casts to sub-vectors

[marc.glisse at normalesup dot org]

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

 Bug #: 53101
   Summary: Recognize casts to sub-vectors
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
Target: x86_64-linux-gnu


Hello,

starting from an AVX __m256d vector x, getting its first element is best done
with *(double*)&x, which is what x[0] internally does, and which generates no
instruction (well, the following has vzeroupper, but let's forget that).
However, *(__m128d*)&x generates 2 movs and I have to explicitly use
_mm256_extractf128_pd to get the proper nop. Could the compiler be taught to
recognize the casts between pointers to vectors of the same object type the
same way it recognizes casts to pointers to that object type?

#include 
#if 0
typedef double T;
#else
typedef __m128d T;
#endif
T f(__m256d x){
  return *(T*)&x;
}

The closest report I found is PR 44551, which is quite different. PR 29881
shows that using a union is not an interesting alternative. I marked this one
as target, but it may very well be that the recognition should be in the
middle-end, or even that the front-end should mark the cast somehow.

[Bug c++/25973] [4.5/4.6/4.7/4.8 Regression] Wrong warning: control reaches end of non-void function

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  2012-04-24 
10:30:45 UTC ---
Noone cares about 4.4 bugs now, that release has reached end-of-life, but the
problem isn't fixed in 4.5, 4.6 or 4.7 so this isn't FIXED

[Bug tree-optimization/52979] [4.7/4.8 Regression] likely wrong code bug w/packed bitfields

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2012-04-24 
10:47:04 UTC ---
Doesn't apparently need a loop, the following fails on 4.7 branch and older
trunk with -O2 -ftree-vectorize as well.  The dummy foo function is important
to reproduce it, apparently otherwise notice_global_symbol is called on a and
creates DECL_RTL for it while it still has DECL_ALIGN 8.  Later on
vect_compute_data_ref_alignment increases the alignment of a to 128 and sets
DECL_USER_ALIGN.

extern void abort (void);
int c, d, e;

void
foo (void)
{
}

struct __attribute__((packed)) S { int g : 31; int h : 6; };
struct S a = { 1 };
static struct S b = { 1 };

void
bar (void)
{
  a.h = 1;
  struct S f = { };
  b = f;
  e = 0;
  if (d)
c = a.g;
}

void
baz (void)
{
  bar ();
  a = b;
}

int
main ()
{
  baz ();
  if (a.g)
abort ();
  return 0;
}

[Bug c++/53102] New: Misplaced 'typename' gives access to private type

[kristian.spangsege at gmail dot com]

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

 Bug #: 53102
   Summary: Misplaced 'typename' gives access to private type
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kristian.spangs...@gmail.com


Here 'typename' is used outside a template, in which case it apparently
invalidly gives access to A::type.


class A {
private:
  typedef int type;
};

class B {
public:
  typedef typename A::type type;
};


int main()
{
  B::type v = 8;
  return v;
}

[Bug target/53101] Recognize casts to sub-vectors

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-24
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-04-24 
11:13:33 UTC ---
We get MEM[(T * {ref-all})&x] for the casting (not a BIT_FIELD_REF for
example).
This gets expanded to

(insn 6 5 7 (set (reg:OI 63)
(subreg:OI (reg/v:V4DF 61 [ x ]) 0)) t.c:8 -1
 (nil))

(insn 7 6 8 (set (reg:V2DF 60 [  ])
(subreg:V2DF (reg:OI 63) 0)) t.c:8 -1
 (nil))

but that should be perfectly optimizable.

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

  Attachment #27228|0   |1
is obsolete||

--- Comment #4 from Janne Blomqvist  2012-04-24 11:17:02 
UTC ---
Created attachment 27229
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27229
Simplified patch

Simplified patch assuming two's complement representation.

[Bug c++/53102] Misplaced 'typename' gives access to private type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-24
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2012-04-24 
11:26:58 UTC ---
4.4 rejects it with:
t.cc:8: error: using 'typename' outside of template

But later releases silently accept it in c++98 or c++11 mode

(N.B. using 'typenme' outside of templates is valid in C++11)

[Bug tree-optimization/52979] [4.7/4.8 Regression] likely wrong code bug w/packed bitfields

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-04-24 
11:41:47 UTC ---
This is a kind of dup of PR48124, certainly on the 4.7 branch that doesn't even
try to handle it, and on the trunk (after Honza's changes one needs to swap
struct S a = { 1 };
static struct S b = { 1 };
lines to reproduce) the problem is I guess that DECL_BIT_FIELD_REPRESENTATIVE
is still an int, I guess in packed bitfields we need to use 8-bit type as bit
field representative, or handle those specially in the expansion.

[Bug tree-optimization/52891] [4.8 Regression] ICE in adjust_bool_pattern

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Jakub Jelinek  2012-04-24 
11:47:12 UTC ---
Fixed.

[Bug target/53065] ICE replace_reg_with_saved_mem, at caller-save.c:1125

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
  Build|4.7.0   |

--- Comment #3 from Georg-Johann Lay  2012-04-24 
11:49:33 UTC ---
Would you please explain why this is a target issue?

The ICE occurs while caller-save.c:save_call_clobbered_regs:858 processes the
following:

(debug_insn 34 33 35 2 (var_location:SF y (concatn:SF [
(reg:SI 16 r16)
(reg:SI 17 r17)
(mem/c:QI (plus:HI (reg/f:HI 32 __SP_L__)
(const_int 13 [0xd])) [29 S1 A8])
(mem/c:QI (plus:HI (reg/f:HI 32 __SP_L__)
(const_int 14 [0xe])) [29 S1 A8])
])) AHRS.cpp:267 -1
 (nil))

save_mode[16] = SImode
save_mode[17] = VOIDmode

replace_reg_with_saved_mem then sees VOIDmode for R17

This looks wrong because R16 overlaps R17. All hard registers are 8 bits wide,
i.e. the next register after (reg:SI 16) is R20.

Obviously some pass generates a bad debug_insn and cannot process it.

The backend does not generate such insns.

[Bug c++/51033] generic vector subscript and shuffle support was not added to C++

[marc.glisse at normalesup dot org]

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

--- Comment #23 from Marc Glisse  2012-04-24 
11:57:22 UTC ---
(In reply to comment #21)
> What does it mean "exercise the backend a lot"? Do you mean it takes a lot of
> time?

I think so.

> I haven't looked at the tests, but I think it is not a problem to run
> compile-only tests with both gcc and g++. 

compile-time tests are not always sufficient.

The __builtin_shuffle tests are spread in:
gcc.dg{,/torture}
gcc.target/{i386,powerpc}
gcc.c-torture/{compile,execute}

I assume the tests in gcc.dg can move to c-c++-common. The target tests should
stay in target. Not sure about gcc.c-torture.

But one interesting thing to test is if the front-end passes the arguments as
constants and thus the backend can use specialized code instead of the slow
generic one. And this kind of test seems necessarily target-specific. Bah, I
guess I shouldn't ask for too much and moving the gcc.dg tests would be enough.

[Bug tree-optimization/52979] [4.7/4.8 Regression] likely wrong code bug w/packed bitfields

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2012-04-24 
11:57:53 UTC ---
But it uses TYPE_SIZE_UNIT to constrain it which is 5, and maxbitsize 40.
Which then leads to a representative of BLKmode via

  if (mode == VOIDmode)
{
  /* We really want a BLKmode representative only as a last resort,
 considering the member b in
   struct { int a : 7; int b : 17; int c; } __attribute__((packed));
 Otherwise we simply want to split the representative up
 allowing for overlaps within the bitfield region as required for
   struct { int a : 7; int b : 7;
int c : 10; int d; } __attribute__((packed));
 [0, 15] HImode for a and b, [8, 23] HImode for c.  */
  DECL_SIZE (repr) = bitsize_int (bitsize);
  DECL_SIZE_UNIT (repr) = size_int (bitsize / BITS_PER_UNIT);
  DECL_MODE (repr) = BLKmode;
  TREE_TYPE (repr) = build_array_type_nelts (unsigned_char_type_node,
 bitsize / BITS_PER_UNIT);

so - where does it go wrong then?

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

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #12 from Paolo Carlini  2012-04-24 
12:12:51 UTC ---
Fixed for 4.8.0.

[Bug c/53085] writes to volatile struct members is missing

[unixoid2003 at mail dot ru]

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

--- Comment #4 from brag  2012-04-24 12:27:29 UTC 
---
Alexander Monakov, As for me it's ok to treat whole struct as non-volatile even
if it has a volatile members when doing smth like this:
struct ss0 a,b;
a=b;
a=b;

Simple example with class:
class aa{
void f();
private:
volatile int a;
};

void aa::f(){
a=0xff;
a=0xff;
}

arm-none-eabi-gcc -O2 -mcpu=cortex-m3 -mthumb -c test.cpp
gcc-4.6.1 compiled:
 <_ZN2aa1fEv>:
   0:   23ffmovsr3, #255; 0xff
   2:   6003str r3, [r0, #0]
   4:   6003str r3, [r0, #0]
   6:   4770bx  lr
The code is right.

gcc-4.7.0 compiled:
 <_ZN2aa1fEv>:
   0:   23ffmovsr3, #255; 0xff
   2:   6003str r3, [r0, #0]
   4:   4770bx  lr
   6:   bf00nop

The code is wrong. It's not ok to write once 'volatile int a' member.

[Bug tree-optimization/52979] [4.7/4.8 Regression] likely wrong code bug w/packed bitfields

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2012-04-24 
12:28:24 UTC ---
Btw, get_best_mode for

Breakpoint 6, get_best_mode (bitsize=6, bitpos=31, bitregion_start=0, 
bitregion_end=39, align=128, largest_mode=DImode, volatilep=0)

happily returns DImode which has more than maxbits (40) bits of size.

I think the C++ memory model work was not sufficiently completed to
handle this case during expansion.

At least

  /* Find the narrowest integer mode that contains the bit field.  */
  for (mode = GET_CLASS_NARROWEST_MODE (MODE_INT); mode != VOIDmode;
   mode = GET_MODE_WIDER_MODE (mode))
{
  unit = GET_MODE_BITSIZE (mode);
  if (unit == GET_MODE_PRECISION (mode)
  && (bitpos % unit) + bitsize <= unit)
break;
}

is overly pessimistic in the (bitpos % unit) + bitsize <= unit check and
does not consider bitpos adjustments.

[Bug tree-optimization/53085] writes to volatile struct members is missing

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-24
  Component|c   |tree-optimization
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #5 from Richard Guenther  2012-04-24 
13:06:40 UTC ---
Confirmed and mine.

[Bug middle-end/53093] [4.8 Regression]: tls/alias-1.c ICE, emutls

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-24
 Ever Confirmed|0   |1

--- Comment #1 from Jan Hubicka  2012-04-24 
13:09:20 UTC ---
mine. Will try to reproduce it on a cross.

[Bug middle-end/53089] [4.8 Regression] gfortran.dg/coarray/atomic_1.f90 and gfortran.dg/coarray/registering_1.f90

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from Jan Hubicka  2012-04-24 
13:10:21 UTC ---
I will take a look. Fortran is lax on finalizing variables (even defined ones)
that are then ignored by IPA passes till wrapup_global_decls.  This might lead
to wrong code.

[Bug tree-optimization/53085] writes to volatile struct members is missing

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2012-04-24 
13:13:26 UTC ---
Patch that applies to all maintained branches (the bug is also in 4.5!)

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 186760)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -4409,6 +4409,7 @@ eliminate (void)
 has the same value number as its rhs.  If so, the store is
 dead.  */
  else if (gimple_assign_single_p (stmt)
+  && !gimple_has_volatile_ops (stmt)
   && !is_gimple_reg (gimple_assign_lhs (stmt))
   && (TREE_CODE (rhs) == SSA_NAME
   || is_gimple_min_invariant (rhs)))

[Bug fortran/40766] this fortran program is too slow

[joseph at codesourcery dot com]

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

--- Comment #23 from joseph at codesourcery dot com  2012-04-24 13:13:13 UTC ---
The glibc libm work has mainly been oriented at correctness rather than 
performance, and postdates the 2.15 release so will be new in 2.16 (the 
2.15 announcement came some time after the actual tag and branching).

[Bug rtl-optimization/52983] [4.8 Regression] internal compiler error: in df_uses_record, at df-scan.c:3243

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2012-04-24 
13:15:35 UTC ---
Caused by recent Alex' changes,
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186422 .

I see two issues:
1) when is dead_debug_insert_temp supposed to be called?  E.g.
word_dce_process_block calls it on all insns if debug.used is present, but
dce_process_block calls it solely on insns that were initially not marked. 
>From looking at df_note_bb_compute I'd assume always, even when the insn stays
if the reg isn't considered live after the insn debug insns still shouldn't
refer to that register.  So, IMHO either the dead_debug_insert_temp should be
in a separate loop, guarded by the same condition as in word_dce_process_block.
Or, if for some reason you really don't want to call it on insns that are
needed, you should again wait after the current loop that sometimes marks
otherwise unneeded insns as needed.

2) dead_debug_insert_temp with DEBUG_TEMP_BEFORE_WITH_VALUE should IMHO for
AUTO_INC_DEC targets call cleanup_auto_inc_dec instead of copy_rtx in the
couple of places where it calls it (and either cleanup_auto_inc_dec should be
made public from combine.c and declared in a header, or it should move to
df-problems.c and combine.c should use it from there).

Alex, what do you think?

[Bug c++/52639] ice in supportable_widening_operation

[vincent-gcc at vinc17 dot net]

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

--- Comment #5 from Vincent Lefèvre  2012-04-24 
13:22:08 UTC ---
Same problem here under Debian/unstable (x86_64), with:

gcc-snapshot -O3 -march=native -std=gnu99 -c ice-setf.i

and the testcase below, using:

gcc (Debian 20120407-1) 4.8.0 20120407 (experimental) [trunk revision 186212]

Here's a simpler testcase:

// /usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.8.0/cc1 -fpreprocessed
ice-setf.i -march=corei7 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt
-mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm
-mno-avx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt --param l1-cache-size=32
--param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7 -quiet
-dumpbase ice-setf.i -auxbase ice-setf -O3 -std=gnu99 -o - -frandom-seed=0
# 1 "ice-setf.i"
int a(int *, unsigned long);
int g(unsigned long);
void r(int, long);

int foo(unsigned long sy, int *x, int i)
{
  unsigned long sx = x[0];
  if (sy <= sx)
{
  unsigned long p = sx * 64;
  int m = 0;
  int tmp = i ? g(sx) : a(&m, sx);
  r(tmp, p);
}
  return 0;
}

The ICE is reproducible with -O3, but not with -O2. Also note that this is C,
not C++.

[Bug target/47197] ICE in gimplify_expr, at gimplify.c:7153 on AltiVec code (vec_dst)

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |wschmidt at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.8.0

[Bug c/53072] automatically set Init() only if option was not set in some other way

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  2012-04-24 13:59:10 UTC ---
On Sun, 22 Apr 2012, manu at gcc dot gnu.org wrote:

> The infrastructure to detect whether options have been set explicitly seems to
> be there, but it is not clear how to use it to fix the above problem.

My notion is that the _set information should move from being a boolean to 
recording the "distance" of the option that set some field from that field 
(it might be set by an option that directly corresponds to the field, or 
by one indirectly implying it, or a default if no relevant option is given 
at all).  Distance is in the sense of appendix 1 of 
.

This is explicitly not a detailed design; anyone implementing it would 
need to flesh out the details.

[Bug c++/52639] ice in supportable_widening_operation

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2012-04-24 
14:04:42 UTC ---
Supposedly fixed by

2012-04-10  Ulrich Weigand  

PR tree-optimization/52870
* tree-vect-patterns.c (vect_recog_widen_mult_pattern): Verify that
presumed pattern statement is within the same loop or basic block.

meaning, I cannot reproduce it.

[Bug c/53072] automatically set Init() only if option was not set in some other way

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez  2012-04-24 
14:10:48 UTC ---
(In reply to comment #1)
> On Sun, 22 Apr 2012, manu at gcc dot gnu.org wrote:
> This is explicitly not a detailed design; anyone implementing it would 
> need to flesh out the details.

Say we have: A enables B enables C. Do we actually need to track that C was
enabled by B or by A? Sorry I cannot imagine what for. 

For warning options, it is sufficient to track the C was enabled by other
option different from C. It seems we have most of the infrastructure to do
this, however, it is unclear how to use this infrastructure to make Init()
useful again, or implement  PR 53063.

[Bug c/53091] Const assignment fails in GCC 4.2, 4.4, 4.6, 4.7 - works fine in clang

[joseph at codesourcery dot com]

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

--- Comment #12 from joseph at codesourcery dot com  2012-04-24 14:25:06 UTC ---
There is no requirement to accept this static initializer, but the code 
does try to be lax about constants in initializers (there is no 
requirement to reject it either) and fold them with c_fully_fold (see 
c-typeck.c:digest_init).  So it may make sense to look at why this laxity 
isn't causing this code to be accepted.

[Bug c++/53000] Conditional operator does not behave as standardized

[ismail at namtrac dot org]

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

--- Comment #1 from İsmail "cartman" Dönmez  
2012-04-24 14:32:34 UTC ---
clang people have the following patch proposed as a workaround to this issue:
http://llvm.org/viewvc/llvm-project/cfe/trunk/www/libstdc%2B%2B4.7-clang11.patch?revision=154890&content-type=text%2Fplain&pathrev=154890

[Bug c/53091] static initializer accepted by clang but not by gcc

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-24
Summary|Const assignment fails in   |static initializer accepted
   |GCC 4.2, 4.4, 4.6, 4.7 -|by clang but not by gcc
   |works fine in clang |
 Ever Confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #13 from Manuel López-Ibáñez  2012-04-24 
14:37:42 UTC ---
(In reply to comment #12)
> There is no requirement to accept this static initializer, but the code 
> does try to be lax about constants in initializers (there is no 
> requirement to reject it either) and fold them with c_fully_fold (see 
> c-typeck.c:digest_init).  So it may make sense to look at why this laxity 
> isn't causing this code to be accepted.

So confirmed.

b...@m8y.org, I would recommend that if you are interested in this, take a more
active role. First, by finding out where and why the C FE does not accept this
code. Then posting the results of your investigation here.

[Bug tree-optimization/53085] writes to volatile struct members is missing

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2012-04-24 
14:41:59 UTC ---
Author: rguenth
Date: Tue Apr 24 14:41:49 2012
New Revision: 186764

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186764
Log:
2012-04-24  Richard Guenther  

PR tree-optimization/53085
* tree-ssa-pre.c (eliminate): Do not eliminate volatile redundant
stores.

* g++.dg/torture/pr53085.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr53085.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug tree-optimization/53085] writes to volatile struct members is missing

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2012-04-24 
14:43:01 UTC ---
Author: rguenth
Date: Tue Apr 24 14:42:53 2012
New Revision: 186765

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186765
Log:
2012-04-24  Richard Guenther  

PR tree-optimization/53085
* tree-ssa-pre.c (eliminate): Do not eliminate volatile redundant
stores.

* g++.dg/torture/pr53085.C: New testcase.

Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/torture/pr53085.C
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/tree-ssa-pre.c

[Bug c/53072] automatically set Init() only if option was not set in some other way

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  2012-04-24 14:43:16 UTC ---
On Tue, 24 Apr 2012, manu at gcc dot gnu.org wrote:

> Say we have: A enables B enables C. Do we actually need to track that C was
> enabled by B or by A? Sorry I cannot imagine what for. 

The idea is that -WB -Wno-B leaves C disabled, but -WB -Wno-A leaves it 
enabled (because -WB is more specific than -Wno-A, it takes precedence 
whatever the ordering of those two options).  If there were any option -WC 
or -Wno-C on the command line, the last such option would apply regardless 
of the -WA / -Wno-A / -WB / -Wno-B options (that much at least is already 
implemented for some option implications).

> For warning options, it is sufficient to track the C was enabled by other
> option different from C. It seems we have most of the infrastructure to do

Even for that, you still need to move away from _set being a boolean, 
since there will be three values (default, explicit -WC / -Wno-C, 
controlled by some other option but not the most specific option).

> this, however, it is unclear how to use this infrastructure to make Init()
> useful again, or implement  PR 53063.

Init() should I think ideally be just for the defaults (with _set 
replacing the present uses of -1 or 2 in Init to mean "not set").

[Bug tree-optimization/53085] [4.7/4.8 Regression] writes to volatile struct members is missing

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.7.1
 Resolution||FIXED
   Target Milestone|--- |4.7.1
Summary|writes to volatile struct   |[4.7/4.8 Regression] writes
   |members is missing  |to volatile struct members
   ||is missing
  Known to fail||4.7.0

--- Comment #9 from Richard Guenther  2012-04-24 
14:45:02 UTC ---
Fixed for 4.7.1.

[Bug c++/53000] Conditional operator does not behave as standardized

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-24
 Ever Confirmed|0   |1

--- Comment #2 from Jonathan Wakely  2012-04-24 
14:47:49 UTC ---
Confirmed.

I suppose we could make the libstdc++ change now rather than waiting for the FE
fix, as it shouldn't change the current behaviour of the library.

[Bug fortran/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #11 from Steve Kargl  
2012-04-24 14:49:18 UTC ---
On Tue, Apr 24, 2012 at 07:57:43AM +, rguenth at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53086
> 
> Richard Guenther  changed:
> 
>What|Removed |Added
> 
>   Component|middle-end  |fortran
> 
> --- Comment #6 from Richard Guenther  2012-04-24 
> 07:57:43 UTC ---
> (In reply to comment #5)
> > (In reply to comment #4)
> > > 
> > > From F2003 standard one finds on page 99:
> > > 
> > >The form variable-name (explicit-shape-spec-list) declares 
> > > variable-name
> > >to have the DIMENSION attribute and specifies the array properties that
> > >apply.
> > > 
> > > My interpretation is that
> > > 
> > >   COMMON /FMCOM / X(1)
> > > 
> > > declares X to have 1 element while
> > > 
> > >   PARAMETER (MEMSIZ=   80 000 000)
> > >   COMMON /FMCOM / X(MEMSIZ)
> > > 
> > > has 8000 elements.  The above appears to be a common
> > > F77 idiom for "dynamic" memory management where the 
> > > programmer is abusing the storage association of element
> > > x(1).
> > 
> > I was told that it was allowed in F77.
> 
> If it is allowed in F77 then the GFortran frontend needs to be fixed. 

Fortran 2008 is backwards compatible with Fortran 2003.
Fortran 2003 is backwards compatible with Fortran 95.
Fortran 95 is backwards compatible with Fortran 90.
Fortran 90 is backwards compatible with Fortran 77.

There are some well-defined exceptions.  None involve COMMON.

F77 states:

  8.3.2 Common Block Storage Sequence

  For each common block, a common block storage sequence is formed
  as follows:

(1) A storage sequence is formed consisting of the storage sequences
of all entities in the lists nlist for the common block.  The order
of the storage sequence is the same as the order of the appearance
of the lists nlist in the program unit.

(2) (Not relevant)

  8.3.3 Size of a Common Block

  The size of a common block is the size of its common block storage
  sequence including any extensions of the sequence resulting from
  equivalence association.

  Within an executable program, all named common blocks that have the
  same name must be the same size.


For the two lines

  COMMON /FMCOM / X(1)

  PARAMETER (MEMSIZ=   80 000 000)
  COMMON /FMCOM / X(MEMSIZ)

the named common block FMCOM have different sizes.  The code
is invalid and abuses the notion that X(1) are storage 
associated.

> First,
> -fbounds-check may not fail, second, the array type in the COMMON aggregate
> type shall not have a defined size (instead it would come from the COMMONs
> DECL_SIZE).
> 
> Thus, this is a frontend bug which is pre-existing with -fbounds-check
> and in 4.8 triggers wrong-code generation.

The bug is in the Fortran code.  Given the following code fragments
from two different subroutine in a program

  COMMON /FMCOM / X(1), A

  PARAMETER (MEMSIZ=   80 000 000)
  COMMON /FMCOM / X(MEMSIZ), B

is A storage associated with B or X(2)?

[Bug c/53072] automatically set Init() only if option was not set in some other way

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  2012-04-24 
14:49:54 UTC ---
(In reply to comment #3)
> 
> Init() should I think ideally be just for the defaults (with _set 
> replacing the present uses of -1 or 2 in Init to mean "not set").

Do you think it is possible to implement just this last part with _set being a
boolean? The code handling -Wb would still need to check explicitly that -Wc is
"not set", but the .opt file infrastructure will take care to set the value
Init() when "not set" after all command-line options have been processed.

[Bug c/53091] static initializer accepted by clang but not by gcc

[bugs at m8y dot org]

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

--- Comment #14 from bugs at m8y dot org 2012-04-24 15:00:42 UTC ---
Heh. Thanks, but our current target is clang->llvm, I was just surprised that
gcc did not accept it.
The codebase being converted by unc0rr's haskell-based tokeniser is pascal
actually.
const
SDL_HAT_UP= $01;
SDL_HAT_RIGHT = $02;
SDL_HAT_RIGHTUP   = SDL_HAT_RIGHT or SDL_HAT_UP;

Sooo, if you guys make it work in GCC, great, could be useful in the future,
maybe for faster game builds on the desktop.
But not really a big priority.  Besides, unc0rr can probably change that to:
enum _consts 
{
SDL_HAT_UP = 0x01,
SDL_HAT_RIGHT = 0x02,
SDL_HAT_RIGHTUP = (SDL_HAT_RIGHT | SDL_HAT_UP)
};

To satisfy gcc's more delicate sensibilities.  :-p

Thanks for looking into it though, and I'll definitely watch the bug.

[Bug middle-end/53088] [4.8 Regression] gcc.target/i386/pr39082-1.c

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  2012-04-24 
15:07:21 UTC ---
At few places in cgraph code we set location to get those late diagnostics
right. It sort of makes sense for function wide diagnostics, but it is not this
one.

(gdb) bt
#0  inform (location=1925, gmsgid=0x379f4b8 "the ABI of passing union with long
double has changed in GCC 4.4") at ../../gcc/diagnostic.c:745
#1  0x029a5f2b in classify_argument (mode=BLKmode, type=0x777a9498,
classes=0x7fffded0, bit_offset=0) at ../../gcc/config/i386/i386.c:6124
#2  0x029a6635 in examine_argument (mode=BLKmode, type=0x777a9498,
in_return=0, int_nregs=0x7fffdf38, sse_nregs=0x7fffdf34) at
../../gcc/config/i386/i386.c:6311
#3  0x029a71e9 in function_arg_advance_64 (cum=0x7fffe090,
mode=BLKmode, type=0x777a9498, words=2, named=1 '\001') at
../../gcc/config/i386/i386.c:6661
#4  0x029a748c in ix86_function_arg_advance (cum_v={magic = 0x4a6f0a0,
p = 0x7fffe090}, mode=BLKmode, type=0x777a9498, named=1 '\001') at
../../gcc/config/i386/i386.c:6715
#5  0x00ea45dd in gimplify_parameters () at ../../gcc/function.c:3572
#6  0x010217b5 in gimplify_body (fndecl=0x777c6100, do_parms=1
'\001') at ../../gcc/gimplify.c:8140
#7  0x01022e0a in gimplify_function_tree (fndecl=0x777c6100) at
../../gcc/gimplify.c:8278
#8  0x00a8a229 in cgraph_analyze_function (node=0x77697750) at
../../gcc/cgraphunit.c:608
#9  0x00a8b472 in cgraph_analyze_functions () at
../../gcc/cgraphunit.c:901
#10 0x00a901cf in cgraph_finalize_compilation_unit () at
../../gcc/cgraphunit.c:2416
#11 0x0050e4f4 in c_write_global_declarations () at
../../gcc/c-decl.c:10043
#12 0x01985ba3 in compile_file () at ../../gcc/toplev.c:572
#13 0x01987f7d in do_compile () at ../../gcc/toplev.c:1939
#14 0x019880d2 in toplev_main (argc=3, argv=0x7fffe7c8) at
../../gcc/toplev.c:2015
#15 0x0074efbb in main (argc=3, argv=0x7fffe7c8) at
../../gcc/main.c:36

I guess the catch is that gimplify_body is the last one knowing what statement
it is looking at.  I would expected expansion to set the source location,
right?
Outputting this on functio ndeclaration, that is still avaiable to the
cummulative arguments API is not quite right, because we would not handle
indirect calls.

Honza

[Bug c/53072] automatically set Init() only if option was not set in some other way

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  2012-04-24 15:09:34 UTC ---
On Tue, 24 Apr 2012, manu at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53072
> 
> --- Comment #4 from Manuel López-Ibáñez  2012-04-24 
> 14:49:54 UTC ---
> (In reply to comment #3)
> > 
> > Init() should I think ideally be just for the defaults (with _set 
> > replacing the present uses of -1 or 2 in Init to mean "not set").
> 
> Do you think it is possible to implement just this last part with _set being a
> boolean? The code handling -Wb would still need to check explicitly that -Wc 
> is
> "not set", but the .opt file infrastructure will take care to set the value
> Init() when "not set" after all command-line options have been processed.

It may be possible - you'd need to avoid implicit setting marking the 
implied option as "set" - and I don't think delaying processing of Init() 
will actually be helpful anyway.

[Bug middle-end/53088] [4.8 Regression] gcc.target/i386/pr39082-1.c

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  2012-04-24 
15:12:36 UTC ---
I guess get_curr_insn_source_location is what I neeed...

[Bug bootstrap/52850] Linker path ends up using wrong zlib

[skunk at iskunk dot org]

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

--- Comment #2 from Daniel Richard G.  2012-04-24 
15:18:33 UTC ---
(In reply to comment #1)
> That sounds like an user problem rather than a GCC issue.

>From the "Installing GCC: Configuration" doc:

--with-system-zlib
Use installed `zlib' rather than that included with GCC. 

If this option was not given (and it wasn't), then GCC should be using its own
zlib, regardless of the presence of other instances of zlib outside of the
build tree.

[Bug target/53065] ICE replace_reg_with_saved_mem, at caller-save.c:1125

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay  2012-04-24 
15:21:36 UTC ---
Author: gjl
Date: Tue Apr 24 15:21:29 2012
New Revision: 186768

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186768
Log:
PR target/53065
* config/avr/avr.h (HARD_REGNO_CALL_PART_CLOBBERED): New hook define.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.h

[Bug target/53065] ICE replace_reg_with_saved_mem, at caller-save.c:1125

[gjl at gcc dot gnu.org]

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

--- Comment #5 from Georg-Johann Lay  2012-04-24 
15:23:51 UTC ---
Author: gjl
Date: Tue Apr 24 15:23:46 2012
New Revision: 186770

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186770
Log:
Backport from 2012-04-24 mainline r186768.
PR target/53065
* config/avr/avr.h (HARD_REGNO_CALL_PART_CLOBBERED): New hook define.


Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/avr/avr.h

[Bug target/53065] ICE replace_reg_with_saved_mem, at caller-save.c:1125

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.1

--- Comment #6 from Georg-Johann Lay  2012-04-24 
15:27:11 UTC ---
Fixed in 4.7.1

[Bug tree-optimization/52979] [4.7/4.8 Regression] likely wrong code bug w/packed bitfields

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  2012-04-24 
15:34:01 UTC ---
Created attachment 27230
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27230
gcc48-pr52979.patch

Untested fix.

[Bug middle-end/53103] New: bug locating unsigned type for non-standard precision

[bigotp at acm dot org]

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

 Bug #: 53103
   Summary: bug locating unsigned type for non-standard precision
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: big...@acm.org


gcc segfaults with this code:

  typedef long int __attribute__((__a20__)) int20_t;
  int20_t xi;
  int20_t addit () { xi += 0x54321L; }

in a back end where xi ends up in mode PSImode which is a MODE_PARTIAL_INT
with 20 bits of precision and 32-bit width.

convert() notices that, because the constant in the add expression is
SImode, there's an SImode add being truncated to a PSImode result, and
pushes the truncation down into the operands.  This ends up in
convert_to_integer, which detects that the signed operation might overflow
so calls unsigned_type_for() to get the unsigned variant.

Unfortunately, this ends up in c_common_type_for_size(), which knows nothing
about PSImode, and returns an unsigned type with 32 bits of precision when
asked for one with 20 bits of precision.  The expression is rewritten with
the 32-bit constant integer recast to the 32-bit unsigned integer (instead
of the 20-bit one it might have used), and infinite recursion through
convert results.

Per http://gcc.gnu.org/ml/gcc/2012-04/msg00805.html, recommendation is to
abort the optimization if the required type is not selected.

[Bug target/47197] ICE in gimplify_expr, at gimplify.c:7153 on AltiVec code (vec_dst)

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from William J. Schmidt  2012-04-24 
15:52:04 UTC ---
Author: wschmidt
Date: Tue Apr 24 15:51:58 2012
New Revision: 186771

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

2012-04-24  Bill Schmidt  

PR target/47197
* config/rs6000/rs6000-c.c (fully_fold_convert): New function.
(altivec_build_resolved_builtin): Call fully_fold_convert.

gcc/testsuite:

2012-04-24  Bill Schmidt  

PR target/47197
* gcc.target/powerpc/pr47197.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr47197.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-c.c
trunk/gcc/testsuite/ChangeLog

[Bug target/47197] ICE in gimplify_expr, at gimplify.c:7153 on AltiVec code (vec_dst)

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from William J. Schmidt  2012-04-24 
15:53:52 UTC ---
Fixed.

[Bug c++/53102] Misplaced 'typename' gives access to private type

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2012-04-24 
16:19:38 UTC ---
>(N.B. using 'typenme' outside of templates is valid in C++11)

That was a Defect report.  
I think my patch to fix PR22154 was not a complete one.

[Bug c++/52363] Presence/absence of -pedantic compilation affects run-time behavior

[paolo at gcc dot gnu.org]

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

--- Comment #12 from paolo at gcc dot gnu.org  
2012-04-24 16:25:33 UTC ---
Author: paolo
Date: Tue Apr 24 16:25:15 2012
New Revision: 186774

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186774
Log:
/cp
2012-04-24  Paolo Carlini  

PR c++/52363
* call.c (tourney, perform_overload_resolution,
build_operator_new_call, build_user_type_conversion_1,
build_user_type_conversion, perform_overload_resolution,
add_template_candidate, add_template_candidate_real,
add_template_conv_candidate, add_builtin_candidates,
add_builtin_candidate, build_builtin_candidate,
add_conv_candidate, add_function_candidate, implicit_conversion,
reference_binding, build_list_conv, conditional_conversion,
add_candidates, can_convert_array, build_aggr_conv,
build_array_conv, build_complex_conv, conditional_conversion):
Add tsubst_flags_t parameter.
(joust): Likewise, use it to handle SFINAE as if pedantic.
(add_list_candidates, build_integral_nontype_arg_conv,
perform_overload_resolution, build_new_function_call,
build_operator_new_call, build_op_call_1,
build_conditional_expr_1, build_new_op_1, convert_like_real,
convert_arg_to_ellipsis, convert_default_arg,
convert_for_arg_passing, build_over_call,
build_new_method_call_1, can_convert_arg, can_convert_arg_bad,
perform_implicit_conversion_flags,
perform_direct_initialization_if_possible,
initialize_reference): Adjust.
* typeck.c (casts_away_constness, casts_away_constness_r):
Add tsubst_flags_t parameter.
(convert_arguments, check_for_casting_away_constness,
build_static_cast_1, build_ptrmemfunc, convert_for_assignment):
Adjust.
* decl.c (reshape_init_r, check_default_argument): Likewise.
* cp-gimplify.c (cxx_omp_clause_apply_fn): Likewise.
* pt.c (convert_nontype_argument, check_non_deducible_conversion):
Likewise.
* init.c (build_new_1): Likewise.
* cvt.c (convert_to_reference, ocp_convert, build_type_conversion,
build_expr_type_conversion, ): Likewise.
* search.c (check_final_overrider): Likewise.
* cp-tree.h (build_user_type_conversion,
build_operator_new_call, can_convert, can_convert_arg,
can_convert_arg_bad, convert_default_arg,
convert_arg_to_ellipsis, convert_for_arg_passing):
Adjust declaration.

/testsuite
2012-04-24  Paolo Carlini  

PR c++/52363
* g++.dg/cpp0x/sfinae35.C: New.
* g++.dg/cpp0x/sfinae36.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae35.C
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae36.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/cvt.c
trunk/gcc/cp/decl.c
trunk/gcc/cp/init.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/search.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/52363] Presence/absence of -pedantic compilation affects run-time behavior

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #13 from Paolo Carlini  2012-04-24 
16:27:58 UTC ---
Fixed for 4.8.0.

[Bug go/51874] Many libgo testsuite failures on IRIX

[ian at airs dot com]

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

--- Comment #16 from Ian Lance Taylor  2012-04-24 16:33:13 
UTC ---
At some point, can you update this bug with the current set of test failures
using Go on Irix?  No rush.

[Bug tree-optimization/52633] [4.7/4.8 Regression] Compiler ICE in vect_is_simple_use_1 (ARM)

[uweigand at gcc dot gnu.org]

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

--- Comment #2 from Ulrich Weigand  2012-04-24 
16:52:59 UTC ---
Some more details on what's going on here:
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01486.html

[Bug tree-optimization/52891] [4.8 Regression] ICE in adjust_bool_pattern

[gjl at gcc dot gnu.org]

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

--- Comment #7 from Georg-Johann Lay  2012-04-24 
17:08:28 UTC ---
Author: gjl
Date: Tue Apr 24 17:08:20 2012
New Revision: 186775

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186775
Log:
PR testsuite/52641
PR tree-optimizations/52891
* gcc.c-torture/compile/pr52891-2.c: Fix test for 16-bit int.


Modified:
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/compile/pr52891-2.c

[Bug testsuite/52641] Test cases fail for 16-bit int targets

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay  2012-04-24 
17:08:28 UTC ---
Author: gjl
Date: Tue Apr 24 17:08:20 2012
New Revision: 186775

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186775
Log:
PR testsuite/52641
PR tree-optimizations/52891
* gcc.c-torture/compile/pr52891-2.c: Fix test for 16-bit int.


Modified:
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/compile/pr52891-2.c

[Bug tree-optimization/52891] [4.8 Regression] ICE in adjust_bool_pattern

[gjl at gcc dot gnu.org]

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

--- Comment #8 from Georg-Johann Lay  2012-04-24 
17:19:03 UTC ---
Author: gjl
Date: Tue Apr 24 17:18:54 2012
New Revision: 186776

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186776
Log:
PR testsuite/52641
PR tree-optimizations/52891
* gcc.c-torture/compile/pr52891-2.c: Fix test for 16-bit int.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/compile/pr52891-2.c

[Bug testsuite/52641] Test cases fail for 16-bit int targets

[gjl at gcc dot gnu.org]

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

--- Comment #5 from Georg-Johann Lay  2012-04-24 
17:19:03 UTC ---
Author: gjl
Date: Tue Apr 24 17:18:54 2012
New Revision: 186776

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186776
Log:
PR testsuite/52641
PR tree-optimizations/52891
* gcc.c-torture/compile/pr52891-2.c: Fix test for 16-bit int.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/compile/pr52891-2.c

[Bug c++/39970] gcc accepts the . dot operator in template arguments

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|gcc-bugs at gcc dot gnu.org |
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.8.0

--- Comment #3 from Paolo Carlini  2012-04-24 
17:32:27 UTC ---
On it.

[Bug c++/52639] ice in supportable_widening_operation

[dcb314 at hotmail dot com]

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

--- Comment #7 from dcb  2012-04-24 18:08:53 UTC ---
(In reply to comment #6)
> Supposedly fixed by
> 
> 2012-04-10  Ulrich Weigand  
> 
> PR tree-optimization/52870
> * tree-vect-patterns.c (vect_recog_widen_mult_pattern): Verify that
> presumed pattern statement is within the same loop or basic block.
> 
> meaning, I cannot reproduce it.

I checked and trunk 20120422 doesn't seem to have this bug.

So it looks fixed to me. Suggest mark resolved.

[Bug middle-end/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer

[dave.anglin at bell dot net]

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

--- Comment #10 from dave.anglin at bell dot net 2012-04-24 18:18:07 UTC ---
On 4/24/2012 5:35 AM, jakub at gcc dot gnu.org wrote:
> What happens on this testcase is
> default_elf_select_rtx_section and the PA specific part of that is just that 
> PA
> needs any constants that need relocations pushed into the constant pool, other
> targets don't.
So, it's probably the procedure labels which cause the problem.

[Bug target/53065] ICE replace_reg_with_saved_mem, at caller-save.c:1125

[webbot at webbot dot org.uk]

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

--- Comment #7 from webbot at webbot dot org.uk 2012-04-24 18:34:41 UTC ---
Don't profess to understand the thread comments - but MANY THANKS for fixing in
4.7.1. Brilliant turnaround

[Bug go/52359] time test is too load-sensitive

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Ian Lance Taylor  2012-04-24 18:35:41 
UTC ---
This should be fixed by the update of libgo to the weekly.2012-03-13 release.

[Bug c++/53000] Conditional operator does not behave as standardized

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #3 from Marc Glisse  2012-04-24 
19:31:52 UTC ---
(In reply to comment #2)
> Confirmed.
> 
> I suppose we could make the libstdc++ change now rather than waiting for the 
> FE
> fix, as it shouldn't change the current behaviour of the library.

It doesn't seem completely obvious to me that this is the right library fix.
What happens if instead of the standard declval you use the trivial version?

  template _Tp __declval2() noexcept;

(except for the obvious problem with indestructible types, but then the decay
version may give you an answer that isn't constructible from the input for
references to a non-copyable type, so that's fair)

Rereading the DR, it appears that some people actually want to decay
independently from this rvalue issue, which is quite a strong change. And after
all, people can use decay, but if decay is included in
common_type, it can't be undone.

Although now that I think as a library writer who has to specialize common_type
for some of his types, I don't really want to specialize it for all cv-ref
variants of my types, so I'd actually like the default common_type to decay not
only the result, but also its arguments! And while we are at it, it could even
try canonicalizing them, like operator auto().

Hmm, I guess you can forget this rant and go ahead (I am still posting it
because there may be real arguments somewhere).

[Bug middle-end/53104] New: convert_move on MODE_PARTIAL_INT does not look for existing conversion

[bigotp at acm dot org]

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

 Bug #: 53104
   Summary: convert_move on MODE_PARTIAL_INT does not look for
existing conversion
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: big...@acm.org


convert_move has special code to handle conversion to and from
MODE_PARTIAL_INT.  Above this code is a comment stating that targets are
expected to provide conversion insns for the MODE_PARTIAL_INT modes they
use.

When presented with a move from HImode to PSImode, however, this code will
unconditionally convert HImode to SImode, then truncate back down to
PSImode.  For cases where both these operations are fairly expensive, it
should instead first check to see whether the target provided the desired
conversion directly.

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

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Ian Lance Taylor  2012-04-24 20:14:09 
UTC ---
Fixed on mainline and 4.7 branch, by creating an intermediate directory.

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at airs dot com]

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

--- Comment #16 from Ian Lance Taylor  2012-04-24 20:43:33 
UTC ---
I think that the problems with the log test should be fixed now.

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

[jb at gcc dot gnu.org]

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

--- Comment #5 from Janne Blomqvist  2012-04-24 21:44:06 
UTC ---
See also PR 36515