[Bug ipa/65087] New: [5 Regression] r220742 causes: ICE:

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65087

Bug ID: 65087
   Summary: [5 Regression] r220742 causes: ICE:
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, jakub at gcc dot gnu.org,
jgreenhalgh at gcc dot gnu.org

Building Firefox with LTO on gcc112 fails during final libxul link
since r220742:

lto1: internal compiler error: in ipcp_verify_propagated_values, at
ipa-cp.c:1057
0x10d1202f ipcp_verify_propagated_values()
../../gcc/gcc/ipa-cp.c:1057
0x10d1415b ipcp_propagate_stage
../../gcc/gcc/ipa-cp.c:2758
0x10d1415b ipcp_driver
../../gcc/gcc/ipa-cp.c:4407
0x10d1415b execute
../../gcc/gcc/ipa-cp.c:4502
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: ../../../gcc_test/usr/local/bin/c++ returned 1 exit
status

A similar issue was fixed a few days ago: PR64978

[Bug c++/65075] [5 Regression] constexpr regression

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65075

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb 17 08:25:30 2015
New Revision: 220748

URL: https://gcc.gnu.org/viewcvs?rev=220748&root=gcc&view=rev
Log:
PR c++/65075
* constexpr.c (check_constexpr_bind_expr_vars): Allow
implicit typedefs for lambda types.

* g++.dg/cpp0x/pr65075.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr65075.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/65075] [5 Regression] constexpr regression

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65075

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug ipa/65087] [5 Regression] r220742 causes: ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1057

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65087

--- Comment #1 from Jakub Jelinek  ---
Created attachment 34786
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34786&action=edit
V491

Can you please try the change suggested by Honza, i.e. only copy over section
if it was user provided (if the flag reflects that?)?  ipa.exp and dg.exp=ipa/*
still pass with it.
If that doesn't help, I'm afraid I'll need to ask Honza or Martin for help.

[Bug ipa/65087] [5 Regression] r220742 causes: ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1057

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65087

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org
   Target Milestone|--- |5.0

[Bug tree-optimization/65084] Lack of type narrowing/widening inhibits good vectorization

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65084

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Note, for masked loads/stores we already have the ability to clone a loop and
only perform changes on the loop that would be vectorized and not on the scalar
code that would be used when not vectorized.  So, if this is performed during
ifcvt or after ifcvt, if such changes wouldn't be generally desirable for
scalar code, but only for vectorization, we can still perform them there.

[Bug target/65064] [5 regression] FAIL: gcc.dg/torture/pr60115.c -O1 (test for excess errors)

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65064

--- Comment #13 from Andreas Schwab  ---
This has the same problem.

[Bug ipa/65087] [5 Regression] r220742 causes: ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1057

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65087

--- Comment #2 from Markus Trippelsdorf  ---
Honza's suggested change works fine.

[Bug ipa/65087] [5 Regression] r220742 causes: ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1057

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65087

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-17
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Thanks.  The question is if it doesn't make just some issue latent, because the
section name will be copied over much less often.
But sure, I can bootstrap/regtest this and ask Honza for review.

[Bug c/65088] New: Does GCC has load/store widening phase?

[m.zakirov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65088

Bug ID: 65088
   Summary: Does GCC has load/store widening phase?
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.zakirov at samsung dot com

This example says me that it doesn't.

$ cat t2.c

int a[2];
int b[2];

int main ()
{
  b[0] = a[0];
  b[1] = a[1];
  return 0;
}

$ gcc t2.c -O3 -S

$ cat t2.s

...

main:
.LFB0:
.cfi_startproc
movla(%rip), %eax
movl%eax, b(%rip)
movla+4(%rip), %eax
movl%eax, b+4(%rip)
xorl%eax, %eax
ret
.cfi_endproc

gcc version is:

commit 71464ecd3a554b889c3bbc53d8874fc532bdf953
Author: trippels 
Date:   Mon Jan 12 07:53:10 2015 +

[Bug debug/64935] [5 Regression] compare debug failure during building of Linux kernel

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64935

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
Any progress on this?

[Bug debug/64935] [5 Regression] compare debug failure during building of Linux kernel

[mkuvyrkov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64935

--- Comment #15 from Maxim Kuvyrkov  ---
Working right now.

I'm trying a second approach to fixing this problem more cleanly.

[Bug tree-optimization/51017] GCC 4.6 performance regression (vs. 4.4/4.5), PRE increases register pressure

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51017

--- Comment #15 from Richard Biener  ---
(In reply to Alexander Peslyak from comment #12)
> (In reply to Richard Biener from comment #11)
> > I wonder if you could share the exact CPU type you are using?
> 
> This is on (dual) Xeon E5420 (using only one core for these benchmarks), but
> there was similar slowdown with GCC 4.6 on other Core 2'ish CPUs as well
> (such as desktop Core 2 Duo CPUs). You might not call these "modern".
> 
> > Note that we have to use movups because [...]
> 
> Thank you for looking into this. I still have a question, though: does this
> mean you're treating older GCC's behavior, where it dared to use movaps
> anyway, a bug?

If you used intrinsics for aligned loads then no.

> I was under impression that with most SSE*/AVX* intrinsics (except for those
> explicitly defined to do unaligned loads/stores) natural alignment is
> assumed and is supposed to be provided by the programmer. Not only with GCC,
> but with compilers for x86(-64) in general. I thought this was part of the
> contract: I use intrinsics and I guarantee alignment. (Things would
> certainly not work for me at least with older GCC if I assumed the compiler
> would use unaligned loads whenever it was unsure of alignment.) Was I wrong,
> or has this changed (in GCC? or in some compiler-neutral specification?), or
> is GCC wrong in not assuming alignment now?

GCC was changed to be more permissive to broken programs and also intrinsics
were changed to map to plain C code in some cases (thus they are not visible
as intrinsics to the compiler).

> Is there a command-line option to ask GCC to assume alignment, like it did
> before?

No.

[Bug tree-optimization/51017] GCC 4.6 performance regression (vs. 4.4/4.5), PRE increases register pressure

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51017

--- Comment #16 from Richard Biener  ---
(In reply to Alexander Peslyak from comment #14)
> For completeness, here are the results for 4.7.x, 4.8.x, and 4.9.0:
> 
> 4.7.0o - 2142K c/s, 29692 bytes, 1267 movaps, 465 movups
> 4.7.0h - 2823K c/s, 29692 bytes, 1732 movaps, 0 movups
> 4.7.4o - 2144K c/s, 29692 bytes, 1267 movaps, 465 movups
> 4.7.4h - 2827K c/s, 29692 bytes, 1732 movaps, 0 movups
> 4.8.0o - 1825K c/s, 27813 bytes, 1341 movaps, 721 movups
> 4.8.0h - 2792K c/s, 27813 bytes, 2062 movaps, 0 movups
> 4.8.4o - 1827K c/s, 27807 bytes, 1341 movaps, 721 movups
> 4.8.4h - 2786K c/s, 27807 bytes, 2062 movaps, 0 movups
> 4.9.0o - 1852K c/s, 28262 bytes, 1319 movaps, 721 movups
> 4.9.0h - 2685K c/s, 28262 bytes, 2040 movaps, 0 movups
> 
> 4.8 produces the smallest code so far, but even with the aligned loads hack
> is still 6% slower than 4.3.
> 
> All of these are with "-O2 -fomit-frame-pointer -Os -funroll-loops
> -finline-functions", like similar results I had posted before.  Xeon E5420,
> x86_64.

I'm completely confused now as to what the original regression was reported
against.  I thought it was the default options in the Makefile, -O2
-fomit-frame-pointer, which showed the regression and you found -Os would
mitigate it somewhat (and I more specifically told you it is -fno-tree-pre that
makes the actual difference).

So - what options give good results with old compilers but bad results with new
compilers?

[Bug sanitizer/65081] -fsanitize=object-size fails with simple pointer arithm

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65081

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
-fno-inline removes the runtime error because __builtin_object_size then can't
determine the size of the object, and -fsanitize=object-size is dependent on
__bos.
E.g., run this slightly modified (printf line added) code:

struct intro
{
  int a;
  char pad_[1];
};

struct intro b;

struct intro *
alloc ()
{
  struct intro *i = &b;
  return i + 1;
}

int
main (void)
{
  struct intro *i = alloc () - 1;
  __builtin_printf ("%zd\n", __builtin_object_size (&i->a, 0));
  i->a = 1;
}

$ xgcc -O e.c; ./a.out 
8
$ xgcc -O e.c -fno-inline; ./a.out 
-1

-1 means that __bos wasn't able to determine the size of an object.

[Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198

--- Comment #19 from Dominique d'Humieres  ---
The test in comment 0 compiles with revision r172608 (2011-04-17), but r173450
(2011-05-05) gives the ICE.

[Bug tree-optimization/62217] [4.9/5 Regression] DOM confuses complete unrolling which in turn causes VRP to warn

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217

--- Comment #10 from rguenther at suse dot de  ---
On Mon, 16 Feb 2015, law at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217
> 
> --- Comment #9 from Jeffrey A. Law  --- Yes, any 
> particular choice has the potential to regress in one way or another. 
> These are heuristics after all.  We're just looking for a reasonable 
> refinement if we can find one.

Well, there is also canonicalization for CSE / jump threading.  Consider

if (i == 2)
 {
   if (i != j)
 ...
   else if (j == 2)
 ...

or

y = 2 * i;
if (i == j)
  x = i + j;

but yes, this is followup transforms.  Unfortunately(?) DOM performs
copy/constant propagation for all recorded equalities.

> Dominance doesn't seem to be the right thing to be looking at to me 
> since the crux of this issue is propagating the "copy" implied by the 
> equality comparison just changes what SSA_NAME we reference and as a 
> result ultimately hides stuff from later passes.  It doesn't (in this 
> case) enable further simplifications or for either SSA_NAME to become 
> unused.  A dominance test between the args of the equality comparison 
> just doesn't seem helpful here.
>
> In fact, because both names are used in the equality test, these 
> propagations can never cause an SSA_NAME to become unused.  At best the 
> propagation will expose some further simplification on one of the paths 
> or it will result in one SSA_NAME having a single use (the comparison).  
> We have no good way of guessing if the former will happen, but we can 
> encourage the latter.

As you say, we don't know - we only know that properly canonicalizing
will expose the followup transforms if there are any.  It looks like
we are basically taking the original order of EQ_EXPR operands
(thus eventually rely on tree_swap_operands canonicalization) plus
the "correctness" thing of taking into account loop depth (which is
kind of a dominance relation).

We are also introducing SSA_NAME_VALUE "chains" in record_equality
as we are setting x SSA_NAME_VALUE to y not to SSA_NAME_VALUE (y)
(we seem to do this in multiple places for some odd reason...,
only tree-ssa-threadedge.c:record_temporary_equivalence seems to get
this right).

> But as I mentioned earlier, I really wonder if we should allow these context
> sensitive equivalences to be expressed in the gimple if they didn't prove
> useful.  And that was the whole purpose behind uncprop -- to find context
> sensitive propagations that ultimately didn't prove useful and which result in
> poor coalescing or unwanted constant initializations and un propagate them.

Yes (but on GIMPLE we don't care).

> It wouldn't directly help this problem because the use is in a normal
> statement, but it's definitely closely related and it wouldn't be hard to
> repurpose that code.  In fact, it might be a good thing to do in general.
> 
> Essentially what it's doing is building a map of values back to SSA_NAMEs 
> which
> hold those values by way of an equality comparison.  At each use of the value,
> we can look at the list of SSA_NAMEs that hold that value and select the one
> that appears to be least cost based on whatever metrics we see fit.

[Bug sanitizer/65081] -fsanitize=object-size fails with simple pointer arithm

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65081

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #2 from Marek Polacek  ---
But yeah, I think we'll need POINTER_DIFF_EXPR to fix this...

[Bug tree-optimization/65077] [4.9 Regression] memcpy generates incorrect code with floating point numbers and -O1

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

--- Comment #16 from rguenther at suse dot de  ---
On Mon, 16 Feb 2015, anders.blomdell at control dot lth.se wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077
> 
> --- Comment #15 from anders.blomdell at control dot lth.se ---
> (In reply to Richard Biener from comment #4)
> > we have similar handling for
> > 
> >   else if (truth_value_p (code))
> > /* Truth value results are not pointer (parts).  Or at least
> >very very unreasonable obfuscation of a part.  */
> > ;
> 
> Isn't this unreachable due to 
> 
> +  case BIT_FIELD_REF:
> 
> in the patch? Or would it be hit if somebody tries to encode pointers with a
> packed bitfield struct/union?

No, truth_value_p is computations such as x = (a == b) or x = (a && b)

> No, I won't write a ridiculous testcase to check :-)
> 
> Again, great thanks.

[Bug libstdc++/65085] Move-assigned empty string corrupt with -D_GLIBCXX_USE_CXX11_ABI=1

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65085

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-02-17
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1
   Severity|normal  |major

--- Comment #1 from Jonathan Wakely  ---
mine

[Bug fortran/65089] New: FAIL: gfortran.dg/io_real_boz(2|_[45]).f90 when tested with -fsanitize=address

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65089

Bug ID: 65089
   Summary: FAIL: gfortran.dg/io_real_boz(2|_[45]).f90 when tested
with -fsanitize=address
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr

I have tested gfortran with

make -k check-gfortran
RUNTESTFLAGS="--target_board=unix'{-m32/-fsanitize=address,-m64/-fsanitize=address}'"

for 95 unexpected failures for -m32 or -m64 (well below what I anticipated!-).

I indeed see pr60576 (assumed_rank_7.f90), pr64921 (class_allocate_18.f90), and
pr64986 (class_to_type_4.f90). I also see 40+ failures associated with scan-*
which are probably expected: -fsanitize=address may change optimizations.
Finally (this PR) the tests gfortran.dg/io_real_boz(2|_[45]).f90 give outputs
of the kind

=
==24090==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00010c37ce04 at pc 0x00010c3948c8 bp 0x7fff53882e40 sp 0x7fff538825f0
READ of size 3 at 0x00010c37ce04 thread T0
#0 0x10c3948c7  (/opt/gcc/gcc4.10w/lib/libasan.2.dylib+0x138c7)
#1 0x10d15f1c5  (/opt/gcc/gcc4.10w/lib/libgfortran.3.dylib+0xc01c5)
#2 0x10c37cd9f 
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10d9f)

0x00010c37ce04 is located 60 bytes to the left of global variable '*LC4'
defined in '/opt/gcc/_clean/gcc/testsuite/gfortran.dg/io_real_boz_5.f90'
(0x10c37ce40) of size 1
0x00010c37ce04 is located 0 bytes to the right of global variable '*LC3'
defined in '/opt/gcc/_clean/gcc/testsuite/gfortran.dg/io_real_boz_5.f90'
(0x10c37ce00) of size 4
...

[Bug ipa/65087] [5 Regression] r220742 causes: ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1057

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65087

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/64823] [5 Regression] false "may be used uninitialized", missed jump threading

[alserkli at inbox dot ru]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64823

Alexander Klimov  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #11 from Alexander Klimov  ---
GDB can now be build with GCC 5.0.0 20150217 even if the GDB patch is undone:

--- a/gdb/symfile.c
+++ b/gdb/symfile.c
@@ -3441,7 +3441,7 @@ static void
 unmap_overlay_command (char *args, int from_tty)
 {
   struct objfile *objfile;
-  struct obj_section *sec = NULL;
+  struct obj_section *sec;

   if (!overlay_debugging)
 error (_("Overlay debugging not enabled.  "

[Bug target/64387] ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -ffloat-store -mavx512er

[tocarip at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64387

--- Comment #4 from tocarip at gcc dot gnu.org ---
Author: tocarip
Date: Tue Feb 17 10:35:12 2015
New Revision: 220755

URL: https://gcc.gnu.org/viewcvs?rev=220755&root=gcc&view=rev
Log:
Backported from mainline
2015-01-14  Ilya Tocar  

PR target/64387
* config/i386/sse.md (vec_unpacks_hi_v8sf): Fix predicate.

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

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr64387.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/i386/sse.md
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/65081] -fsanitize=object-size fails with simple pointer arithm

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65081

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |5.0

--- Comment #3 from Jakub Jelinek  ---
I think we should just make the IFN_OBJECT_SIZE expansion smarter.
In particular, we pass 3 interesting arguments to IFN_OBJECT_SIZE:
addr, addr - base, __builtin_object_size (base, 0) (we use ptr, offset, size
names for those).
The latter two are sizetype, so unsigned, but really, if addr - base is
"negative", then we shouldn't call __ubsan_handle*.
Now, the question is what to treat as "negative".  One possibility is just to
look at the sign of the second argument, cheaper, but might not be appropriate.
The other possibility is to check if ptr + offset < ptr and not warn in that
case, that is slower, but perhaps more precise.  Of course the comparison would
need to be performed on integers, so (unsigned long) ptr > (unsigned long) ptr
+ offset or so.  And, it could be done only after the initial comparison, so it
wouldn't affect programs not hit by this sanitizer bug before, other than
growing -fsanitize=undefined code size.

[Bug other/64452] [4.8/4.9/5.0 Regression] ICE in avr-gcc when passing struct member to varargs function

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64452

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 34787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34787&action=edit
Tentative patch for 5.0

[Bug sanitizer/65081] -fsanitize=object-size fails with simple pointer arithm

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65081

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #4 from Marek Polacek  ---
Thus mine.

[Bug tree-optimization/65084] Lack of type narrowing/widening inhibits good vectorization

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65084

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-17
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.  Btw, this is just the lack of shorten_* on the GIMPLE level.  For
your match.pd pattern it is a matter of simplifying/changing it slightly:

Index: match.pd
===
--- match.pd(revision 220751)
+++ match.pd(working copy)
@@ -1031,31 +1031,22 @@ (define_operator_list CBRT BUILT_IN_CBRT
operation and convert the result to the desired type.  */
 (for op (plus minus)
   (simplify
-(convert (op (convert@2 @0) (convert@3 @1)))
+(convert (op:c@4 (convert@2 @0) (convert?@3 @1)))
 (if (INTEGRAL_TYPE_P (type)
-/* We check for type compatibility between @0 and @1 below,
-   so there's no need to check that @1/@3 are integral types.  */
 && INTEGRAL_TYPE_P (TREE_TYPE (@0))
-&& INTEGRAL_TYPE_P (TREE_TYPE (@2))
+&& INTEGRAL_TYPE_P (TREE_TYPE (@4))
 /* The precision of the type of each operand must match the
precision of the mode of each operand, similarly for the
result.  */
 && (TYPE_PRECISION (TREE_TYPE (@0))
 == GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (@0
-&& (TYPE_PRECISION (TREE_TYPE (@1))
-== GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (@1
-&& TYPE_PRECISION (type) == GET_MODE_PRECISION (TYPE_MODE (type))
 /* The inner conversion must be a widening conversion.  */
 && TYPE_PRECISION (TREE_TYPE (@2)) > TYPE_PRECISION (TREE_TYPE (@0))
-&& ((GENERIC 
- && (TYPE_MAIN_VARIANT (TREE_TYPE (@0))
- == TYPE_MAIN_VARIANT (TREE_TYPE (@1)))
- && (TYPE_MAIN_VARIANT (TREE_TYPE (@0))
- == TYPE_MAIN_VARIANT (type)))
-|| (GIMPLE
-&& types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1))
-&& types_compatible_p (TREE_TYPE (@0), type
+/* The final precision should match that of operand @0.  */
+&& TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0))
+/* Make sure the wide operation is dead after the transform.  */
+&& (TREE_CODE (@4) != SSA_NAME || has_single_use (@4)))
   (if (TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0)))
-   (convert (op @0 @1)))
+   (convert (op @0 (convert @1
   (with { tree utype = unsigned_type_for (TREE_TYPE (@0)); }
(convert (op (convert:utype @0) (convert:utype @1)))

to allow for constant @1 (where the convert would be folded into the constant
itself).  And we then get before vectorization:

  :
  # i_17 = PHI 
  # ivtmp_30 = PHI 
  _5 = a[i_17];
  _6 = (char) _5;
  _7 = (unsigned short) _6;
  _9 = b[i_17];
  _3 = (unsigned short) _9;
  _14 = _3 + 17;
  _10 = _7 + _14;
  _11 = (short int) _10;
  a[i_17] = _11;
  i_13 = i_17 + 1;
  ivtmp_29 = ivtmp_30 - 1;
  if (ivtmp_29 != 0)
goto ;

and much better code.

I've added a single-use restriction to the arithmetic result and allow
the commutated form to match so we also get at (short)((long long)x + ((long
long)y + 12))).

[Bug target/64452] [4.8/4.9/5.0 Regression] ICE in avr-gcc when passing struct member to varargs function

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64452

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords|ra  |
   Priority|P3  |P4
  Component|other   |target

[Bug tree-optimization/62630] [5 regression] gcc.dg/graphite/vect-pr43423.c FAILs

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630

--- Comment #6 from Richard Biener  ---
I think we have to XFAIL the testcase - the graphite folks seem to be gone
again.

[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076

--- Comment #6 from Richard Biener  ---
I wonder where the main _int_malloc load comes from.

[Bug target/55701] Inline some instances of memset for ARM

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55701

Richard Earnshaw  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug go/64999] s390x libgo test failure in TestMemoryProfiler

[vogt at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999

--- Comment #17 from Dominik Vogt  ---
runtime.Callers is not called in this test case, so changing it won't help.

[Bug target/65064] [5 regression] FAIL: gcc.dg/torture/pr60115.c -O1 (test for excess errors)

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65064

--- Comment #14 from Andreas Schwab  ---
I've accidentally tested with both patches applied, will try again with only
the first one.

[Bug target/64387] ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -ffloat-store -mavx512er

[tocarip at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64387

--- Comment #5 from tocarip at gcc dot gnu.org ---
Author: tocarip
Date: Tue Feb 17 11:41:55 2015
New Revision: 220756

URL: https://gcc.gnu.org/viewcvs?rev=220756&root=gcc&view=rev
Log:
Backported from mainline
2015-01-14  Ilya Tocar  

PR target/64387
* config/i386/sse.md (vec_unpacks_hi_v8sf): Fix predicate.
(vec_unpacks_hi_v16sf): Ditto.

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

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr64387.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/i386/sse.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/65063] [4.8/4.9/5 Regression] gcc.dg/vect/vect-double-reduc-6.c FAILs with -O3 -fno-tree-loop-ivcanon -fno-tree-vectorize

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65063

--- Comment #3 from Richard Biener  ---
The tail loop ends up with completely off initial conditions because its
values are computed before pcom transform which ends up releasing the
SSA names used therein.  Then unrolling assigns some random new SSA names
to them.

So it seems to me that pcom doesn't deal with the case of a tail loop
at all - at least it doesn't compute entry values for that.  There isn't
a 1:1 relation between the values either and the old IVs are removed.
Also there seems to be always at least one tail iteration.

In the existing testcases the old IVs simply don't become dead.

So we have to restrict unrolling to the case where we don't replace looparound
PHIs.

[Bug go/64999] s390x libgo test failure in TestMemoryProfiler

[vogt at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999

--- Comment #18 from Dominik Vogt  ---
Created attachment 34788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34788&action=edit
Different fix

How about this patch to the callback() function in go-callers.c to modify the
incoming pc.  The algorithm to do this is moved from ppfor.go to go-callers.c.

[Bug c/65083] Can not indirectly call some C11 atomic library functions

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65083

--- Comment #1 from joseph at codesourcery dot com  ---
Presumably libatomic should get trivial wrappers for the macros, and 
stdatomic.h should add corresponding function declarations.

[Bug libstdc++/65085] [5 Regression] Move-assigned empty string corrupt with -D_GLIBCXX_USE_CXX11_ABI=1

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65085

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|Move-assigned empty string  |[5 Regression]
   |corrupt with|Move-assigned empty string
   |-D_GLIBCXX_USE_CXX11_ABI=1  |corrupt with
   ||-D_GLIBCXX_USE_CXX11_ABI=1

--- Comment #2 from Jonathan Wakely  ---
Fixed.

[Bug libstdc++/65085] [5 Regression] Move-assigned empty string corrupt with -D_GLIBCXX_USE_CXX11_ABI=1

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65085

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue Feb 17 12:44:26 2015
New Revision: 220758

URL: https://gcc.gnu.org/viewcvs?rev=220758&root=gcc&view=rev
Log:
PR libstdc++/65085
* include/bits/basic_string.h (basic_string(basic_string&&)): Ensure
empty string gets null-terminated.
* testsuite/21_strings/basic_string/cons/char/65085.cc: New.

Added:
trunk/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/65085.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/basic_string.h

[Bug go/64999] s390x libgo test failure in TestMemoryProfiler

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999

--- Comment #19 from Ian Lance Taylor  ---
I see a call to runtime.Callers in Profile.Add in
libgo/go/runtime/pprof/pprof.go.  If the PC values in question do not come from
there, where do they come from?

[Bug tree-optimization/62217] [4.9/5 Regression] DOM confuses complete unrolling which in turn causes VRP to warn

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217

Richard Biener  changed:

   What|Removed |Added

   Keywords|diagnostic  |

--- Comment #11 from Richard Biener  ---
Note that the diagnostic part is fixed for GCC 5.  We are still somehow not
removing dead code.

[Bug bootstrap/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009

--- Comment #17 from David Edelsohn  ---
Sorry, I am trying to separate out the patches.  It should have been stdlib.h
not inttypes.h.  I corrected the commit.

[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348

--- Comment #13 from David Edelsohn  ---
The GCC build process has requirements, including SVR4/POSIX awk.  GCC works on
a wide variety of systems, but needs to have a base set of requirements and
limit accommodation to prevent things from getting out of control.  Building
and installing Gawk or Nawk or another implementation is not an unreasonable
burden.

[Bug tree-optimization/62217] [4.9/5 Regression] DOM confuses complete unrolling which in turn causes VRP to warn

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217

--- Comment #12 from Richard Biener  ---
Index: gcc/tree-ssa-dom.c
===
--- gcc/tree-ssa-dom.c  (revision 220755)
+++ gcc/tree-ssa-dom.c  (working copy)
@@ -2291,11 +2291,16 @@ cprop_operand (gimple stmt, use_operand_
   if (!may_propagate_copy (op, val))
return;

-  /* Do not propagate copies into simple IV increment statements.
- See PR23821 for how this can disturb IV analysis.  */
-  if (TREE_CODE (val) != INTEGER_CST
- && simple_iv_increment_p (stmt))
-   return;
+  /* Do not propagate copies into BIVs.
+ See PR23821 and PR62217 for how this can disturb IV and
+number of iteration analysis.  */
+  if (TREE_CODE (val) != INTEGER_CST)
+   {
+ gimple def = SSA_NAME_DEF_STMT (op);
+ if (gimple_code (def) == GIMPLE_PHI
+ && gimple_bb (def)->loop_father->header == gimple_bb (def))
+   return;
+   }

   /* Dump details.  */
   if (dump_file && (dump_flags & TDF_DETAILS))


fixes the warning on the branch, not sure yet if the missed-optimization on
the trunk.  It extends an existing heuristic to not replace a BIV use
in an increment to not replace any BIV use (???  Best if we'd know if the
equivalence were temporary only...)

[Bug middle-end/65090] New: GCC produces instruction with bad alignment on SPARC when using -O

[dirk.bo...@inform-ac.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65090

Bug ID: 65090
   Summary: GCC produces instruction with bad alignment on SPARC
when using -O
   Product: gcc
   Version: 4.7.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dirk.bo...@inform-ac.com

Created attachment 34789
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34789&action=edit
Complete source code

$ uname -a
SunOS uxs450 5.10 Generic_150400-17 sun4v sparc sun4v Solaris
$ g++-4.7 -v
Using built-in specs.
COLLECT_GCC=g++-4.7
COLLECT_LTO_WRAPPER=/opt/its/runtime/gcc/4.7/libexec/gcc/sparc-sun-solaris2.10/4.7.4/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with:
/SSD/compile/toolsexternal/packages/gcc-4.7/work/gcc-4.7.4/configure
--prefix=/opt/its/runtime/gcc/4.7 --program-suffix=-4.7
--enable-languages=c,c++ --disable-multilib --disable-nls
--enable-threads=posix --enable-__cxa_atexit --enable-libstdcxx-debug
--with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 4.7.4 (GCC) 

I got it down to two small files (see attachment). Reproduce it like this:

$ g++-4.7 -O -std=gnu++11 -c t.cc 
$ g++-4.7 -O -std=gnu++11 -c t2.cc 
$ g++-4.7 -O -std=gnu++11 -c t.cc 
$ g++-4.7 -O -std=gnu++11 -c t2.cc 
$ g++-4.7 -o t t.o t2.o
$ ./t 
Bus Error (core dumped)

The code generated for "somefunction" is broken:
00010a68 <_Z12somefunctionv>:
   10a68:   9d e3 bf 80 save  %sp, -128, %sp
   10a6c:   c0 27 bf e4 clr  [ %fp + -28 ]
   10a70:   c0 27 bf e8 clr  [ %fp + -24 ]
   10a74:   c0 27 bf ec clr  [ %fp + -20 ]
   10a78:   c0 27 bf f0 clr  [ %fp + -16 ]
   10a7c:   c0 27 bf fb clr  [ %fp + -5 ]
   ...

"%fp - 5" is not 4 bytes aligned and causes the bus error.

The function somefunction is in t.cc (attached), the relevant part is:
  struct X {
size_t a = 0;
std::vector vec_;

X() {
  vec_.emplace_back(nullptr);
}
  };
  void somefunction()
  {
X cv;
f2(string());
  }

[Bug c++/65091] New: decltype(~arg) fails for template functions

[ptomulik at meil dot pw.edu.pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65091

Bug ID: 65091
   Summary: decltype(~arg) fails for template functions
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ptomulik at meil dot pw.edu.pl

Created attachment 34790
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34790&action=edit
ii file generated by -save-temps

The following program does not compile with g++ (although it compiles with
clang++):

template
auto foo(T x) -> decltype(~x)
{ return ~x; }

int bar()
{ return foo(10); }

ptomulik@tea:$ g++ -std=c++11 -g -O0 -Wall -Wextra -Werror -pedantic -c -o
test.o test.cpp
test.cpp: In function ‘int bar()’:
test.cpp:6:16: error: no matching function for call to ‘foo(int)’
 { return foo(10); }
^
test.cpp:6:16: note: candidate is:
test.cpp:2:6: note: template decltype (~ x) foo(T)
 auto foo(T x) -> decltype(~x)
  ^
test.cpp:2:6: note:   template argument deduction/substitution failed:
test.cpp: In substitution of ‘template decltype (~ x) foo(T) [with T =
int]’:
test.cpp:6:16:   required from here
test.cpp:2:6: error: ‘x’ was not declared in this scope
test.cpp:6:19: error: control reaches end of non-void function
[-Werror=return-type]
 { return foo(10); }
   ^
cc1plus: all warnings being treated as errors


This is specific to the unary operator "~" and expression involving argument
name (not its type). All the following variants compile well for instance:

template
auto foo(T x) -> decltype(!x)
{ return !x; }

template
auto foo(T x) -> decltype(-x)
{ return -x; }

template
auto foo(T x) -> decltype(+x)
{ return +x; }

template
auto foo(T x) -> decltype(~T())
{ return ~x; }

My gcc is:

ptomulik@tea:$ g++ --version
g++-4.9.real (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

My OS is Debian 8.0.

[Bug tree-optimization/65084] Lack of type narrowing/widening inhibits good vectorization

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65084

howarth at bromo dot med.uc.edu changed:

   What|Removed |Added

 CC||howarth at bromo dot med.uc.edu

--- Comment #3 from howarth at bromo dot med.uc.edu ---
I assume that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65088 is a
duplicate?

[Bug tree-optimization/62217] [4.9/5 Regression] DOM confuses complete unrolling which in turn causes VRP to warn

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217

--- Comment #13 from Jeffrey A. Law  ---
On 02/17/15 02:44, rguenther at suse dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217
>
> --- Comment #10 from rguenther at suse dot de  ---
> On Mon, 16 Feb 2015, law at redhat dot com wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217
>>
>> --- Comment #9 from Jeffrey A. Law  --- Yes, any
>> particular choice has the potential to regress in one way or another.
>> These are heuristics after all.  We're just looking for a reasonable
>> refinement if we can find one.
>
> Well, there is also canonicalization for CSE / jump threading.  Consider
>
> if (i == 2)
>   {
> if (i != j)
>   ...
> else if (j == 2)
>   ...
>
> or
>
> y = 2 * i;
> if (i == j)
>x = i + j;
>
> but yes, this is followup transforms.  Unfortunately(?) DOM performs
> copy/constant propagation for all recorded equalities.
Yea, I've been mulling what it would take to instead build equivalence 
classes, then when we find a use walk through the class and see which 
one is "best".  I suspect the vast majority of the time the "best" is 
always going to be the same -- the major exception will be these 
temporary equivalences.   I've also been pondering somehow marking the 
equivalent values with some kind of tag indicating their scope and using 
that to guide propagation.

But I haven't prototyped anything...


>
> As you say, we don't know - we only know that properly canonicalizing
> will expose the followup transforms if there are any.  It looks like
> we are basically taking the original order of EQ_EXPR operands
> (thus eventually rely on tree_swap_operands canonicalization) plus
> the "correctness" thing of taking into account loop depth (which is
> kind of a dominance relation).
Correct, we take it from the original order and thus from the earlier 
canonicalization via tree_swap_operands.

>
> We are also introducing SSA_NAME_VALUE "chains" in record_equality
> as we are setting x SSA_NAME_VALUE to y not to SSA_NAME_VALUE (y)
> (we seem to do this in multiple places for some odd reason...,
> only tree-ssa-threadedge.c:record_temporary_equivalence seems to get
> this right).
Even if we set to SSA_NAME_VALUE (y) we can end up with chains.  But 
this change might eliminate the benefit of the chain walk, which would 
be good.

Jeff

[Bug middle-end/65090] GCC produces instruction with bad alignment on SPARC when using -O

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65090

--- Comment #1 from Mikael Pettersson  ---
I can reproduce the wrong-code with g++ 4.7.4 on sparc64-linux, but g++ 4.8.4
and 5 (current trunk) work.

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028

--- Comment #15 from H.J. Lu  ---
(In reply to Jan Hubicka from comment #14)
> Thanks for looking into that!
> > 
> > Why do we think rPrimary is 16-byte aligned when it is only 8-byte aligned?
> 
> ipa-cp newly does alignment propagation.  You may try to just disable it
> by short cirucuiting ipcp_store_alignment_results

Disable ipcp_store_alignment_results fixes the bug.

> (also you ought to be able to find the wrong alignment upgrade in the ipa-cp
> dumps)

I will do it next.

[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h

[skunk at iskunk dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53348

--- Comment #14 from Daniel Richard G.  ---
(In reply to David Edelsohn from comment #13)
> The GCC build process has requirements, including SVR4/POSIX awk.  GCC works
> on a wide variety of systems, but needs to have a base set of requirements
> and limit accommodation to prevent things from getting out of control. 

I understand that; my point is, escaping a couple of characters falls under the
rubric of "limited accommodation." It would be a different story if I wanted
GCC to build with an awk that, say, doesn't support variables.

> Building and installing Gawk or Nawk or another implementation is not an
> unreasonable burden.

It's less reasonable than a two-line patch.

(Any info on building a dist tarball? I don't have enough space on my AIX 4.3
system to take the entire SVN tree)

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028

--- Comment #16 from H.J. Lu  ---
Created attachment 34791
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34791&action=edit
A patch to add -fipa-cp-alignment

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028

H.J. Lu  changed:

   What|Removed |Added

  Attachment #34791|0   |1
is obsolete||

--- Comment #17 from H.J. Lu  ---
Created attachment 34792
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34792&action=edit
A corrected patch to add -fipa-cp-alignment

[Bug middle-end/65074] [5 Regression] r220674 broke C++ PIEs

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65074

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Jan Hubicka  ---
Hi,
as Jakub noticed I just fixed the same bug independently by
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01004.html

The fix is bit different. It adds DECL_EXTERNAL check in addition to
node->definition.

Concerning discussion here, node->definition really just means that the
definition is there at the time you check the flag.  It does not imply it will
be output - it can be removed later by IPA optimization or it may be a
definition of external variable or alias.

Using node->process flag is not a good idea, because these flags are set only
while generating final assembler output, while we use binds_local_p during IPA
optimization, too.

I see nothing wrong with dropping the use of ->definition flag as suggested by
Richard. It is probably good cleanup compared to my change. The lto-cgraph.c
and symtab.c parts of my change are still useful to fix some of nonsenses WRT
definitions and ltrans partitions.

Honza

[Bug tree-optimization/65084] Lack of type narrowing/widening inhibits good vectorization

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65084

--- Comment #4 from Jeffrey A. Law  ---
It's related.  There's enough of these BZs, that it might make sense to create
a meta-but to track all of them.  I'm particularly interested in the narrowing
case as replacement of shorten_binary_op/shorten_compare from the C/C++
front-ends with match.pd patterns seems like a long term maintenance win.

[Bug middle-end/65090] GCC produces instruction with bad alignment on SPARC when using -O

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65090

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
4.7.x is no longer supported, so if that is the case, there is nothing to do.

[Bug target/63501] ICE in GCC powerpc64le top of trunk with -mupper-regs-df

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63501

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Peter Bergner  ---
This is fixed now.

[Bug libstdc++/65092] New: Container adaptors missing allocator-extended constructors

[rs2740 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65092

Bug ID: 65092
   Summary: Container adaptors missing allocator-extended
constructors
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com

The allocator-extended constructors of std::stack, std::queue and
std::priority_queue are missing.

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028

--- Comment #18 from H.J. Lu  ---
There are

;; Function operator* (_ZmlRK10ggSpectrumS1_, funcdef_no=48, decl_uid=4292,
cgraph_uid=5, symbol_order=46520)

Modification phase of node operator*/46520
  Adjusting alignment of param 1 to 16, misalignment to 0

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028

--- Comment #19 from Martin Jambor  ---
HJ, how do I configure build an x32 gcc?  I have working x32 debian
chroot environment but building gcc fails with:

checking for int64_t underlying type... long long
configure: error: error verifying int64_t uses long long
Makefile:4053: recipe for target 'configure-gcc' failed

is there a howto somewhere?  Thanks.

[Bug middle-end/65093] New: [5 Regression] 26_numerics/random/binomial_distribution/operators/values.cc times out

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65093

Bug ID: 65093
   Summary: [5 Regression]
26_numerics/random/binomial_distribution/operators/val
ues.cc times out
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
  Host: x86_64-linux-gnu
Target: cris-elf

This test used to pass.  Since a commit in the range (220738:220744]it fails
for cris-elf as follows:

Running
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
[...]

WARNING: program timed out.
FAIL: 26_numerics/random/binomial_distribution/operators/values.cc execution
test

(no further information in the .log file)

There were no changes to libstdc++-v3 in the revision range.  Apparently the
middle-end changed such that code quality suffered enough that the test now
times out on the machine where I run autototests.  I'm going to bisect the
middle-end changes in the revision range and inspect the code.

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028

--- Comment #20 from Jan Hubicka  ---
H.J. Can you, please attach the full .cp dump file and release_ssa dump of the
corresponding functions?
The -fipa-cp-alignment patch looks like a resonable idea.  These days you want
to check opt_for_fn (decl, flag_ipa_cp_alignment). Ok with that change and
documentation update.

Honza

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028

--- Comment #21 from H.J. Lu  ---
(In reply to Martin Jambor from comment #19)
> HJ, how do I configure build an x32 gcc?  I have working x32 debian
> chroot environment but building gcc fails with:

I suggest you use Ubuntu 14.04 or newer.

> checking for int64_t underlying type... long long
> configure: error: error verifying int64_t uses long long
> Makefile:4053: recipe for target 'configure-gcc' failed

What does gcc/config.log say?

> is there a howto somewhere?  Thanks.

You just need to install gcc x32 as well as libc x32 packages.

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028

--- Comment #22 from H.J. Lu  ---
Created attachment 34793
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34793&action=edit
Dumps from -fdump-ipa-cp-details

[Bug rtl-optimization/64033] [5 Regression] ICE: in expand_expr_addr_expr_1, at expr.c:7741

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64033

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-02-17
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Judging from your own gcc-testresult posts, this went away in between 20141216
(where it still failed) and 20141220 (where it no longer shows up).  Can we
close this?

[Bug target/61949] [5 regression] SEGV compiling gcc.dg/pch/import-[12].c

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Judging from gcc-testresults, this was showing up in late July and early
August, but already can't be seen e.g. in r213757.  Has it been fixed?  Can
this be closed?

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028

--- Comment #23 from H.J. Lu  ---
(In reply to Jan Hubicka from comment #20)
> The -fipa-cp-alignment patch looks like a resonable idea.  These days you
> want to check opt_for_fn (decl, flag_ipa_cp_alignment). Ok with that change
> and documentation update.
> 

A patch is posted at:

https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01043.html

[Bug c++/65094] New: An initializer_list cannot be copied with brace syntax

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65094

Bug ID: 65094
   Summary: An initializer_list cannot be copied with brace syntax
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com

#include 

template  void copy_it(T t)
{
T t2{t}; // #1
}

int main()
{
std::initializer_list x{1,2,3};
std::initializer_list y{x}; // #2
copy_it(x);
}

Both the direct-initialization of a copy in the template (#1) and in the
non-template code (#2) are ill-formed according to gcc. Clang accepts both.
gcc accepts the code if parens are used instead of braces.

[Bug target/62251] [5 Regression] FAIL: gfortran.dg/quad_2.f90 execution test

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62251

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-02-17
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek  ---
Yes, can you please debug this?
Try e.g. GCC 5 compiled testcase against 4.9 libgfortran or vice versa, if the
difference is in the binaries, do side-by-side debugging of the 4.9 and 5
version in the debugger and watch where things differ, if it is on the library
side, identify which call differs?

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028

--- Comment #24 from H.J. Lu  ---
(In reply to H.J. Lu from comment #18)
> There are
> 
> ;; Function operator* (_ZmlRK10ggSpectrumS1_, funcdef_no=48, decl_uid=4292,
> cgraph_uid=5, symbol_order=46520)
> 
> Modification phase of node operator*/46520
>   Adjusting alignment of param 1 to 16, misalignment to 0

IPA-CP missed _ZN18eonImageCalculatorC1Ev which calls
_ZmlRK10ggSpectrumS1_ with 8-byte aligned rPrimary.

[Bug other/65095] New: Adapt OpenMP diagnostic messages for OpenACC

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65095

Bug ID: 65095
   Summary: Adapt OpenMP diagnostic messages for OpenACC
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: minor
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org

GCC's OpenACC implementation is sharing a lot of code with the GCC OpenMP
implementation, and there are still a lot of code paths where the diagnostic
messages (compiler warnings, errors) are hard-coded to OpenMP idioms.

[Bug rtl-optimization/64033] [5 Regression] ICE: in expand_expr_addr_expr_1, at expr.c:7741

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64033

John David Anglin  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from John David Anglin  ---
Fixed.

[Bug tree-optimization/62217] [4.9/5 Regression] DOM confuses complete unrolling which in turn causes VRP to warn

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217

--- Comment #14 from Jeffrey A. Law  ---
WRT the patch in c#12, it looks reasonable for the same reasons as we avoid
propagating in 23821.  I can confirm that it prevents the unwanted cprop into
array reference.   By DOM2 we have the following array references:


  g_x[0] = *x2_9(D);
  g_x[0] = *x1_7(D);
  g_x[1] = *x2_9(D);
  g_x[1] = *x1_7(D);
  g_x[2] = *x2_9(D);
  g_x[2] = *x1_7(D);
  g_x[3] = *x1_7(D);
  g_x[3] = *x2_9(D);


Assuming it bootstraps and regression tests, I'd go with it.

[Bug tree-optimization/62630] [5 regression] gcc.dg/graphite/vect-pr43423.c FAILs

[mircea.namolaru at inria dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630

Mircea Namolaru  changed:

   What|Removed |Added

 CC||mircea.namolaru at inria dot fr

--- Comment #7 from Mircea Namolaru  ---
Graphite generates MAX/MIN expressions.

I've modified Graphite to use the original types of "n" and "mid" in MIN and
MAX, and to not generate the casts of "n" and "mid" to a longer signed INT
before MIN/MAX, and the vectorization succeeded.

It seems that it is not a Graphite problem but a scalar evolution one. Scalar
evolution is not able to handle MIN/MAX expressions in the presence of casts.
Beside vectorization also further unrolling is prevented.

[Bug fortran/64506] FORMAT Parse Error with Continuation Line

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64506

--- Comment #5 from Jerry DeLisle  ---
Fixed on trunk, any other cases identified, please let me know.  I will hold
this open for a while just in case.

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028

--- Comment #25 from H.J. Lu  ---
IPA dump uses node->name () instead of node->asm_name ().
node->name () is kind of useless here.

[Bug lto/65012] [5 Regression] systemd fails to build at least on ppc64el, powerpc, arm-inux-gnueabihf and aarch64 with -flto (ICE)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65012

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
So, I've managed to reproduce some crash on aarch64, but whether it is the same
one you saw is unclear.
In any case, the backtrace is:
(gdb) p lto_file_data
$3 = (lto_file_decl_data *) 0x0
(gdb) bt
#0  lto_get_decl_name_mapping (decl_data=decl_data@entry=0x0,
name=0x3ffaf719e00 "__PRETTY_FUNCTION__.9700") at
../../gcc/lto-section-in.c:369
#1  0x00ad3f90 in varpool_node::get_constructor (this=0x3ffaf8ea800) at
../../gcc/varpool.c:315
#2  0x00acca64 in get_variable_section (decl=decl@entry=0x3ffaf6c1e60,
prefer_noswitch_p=prefer_noswitch_p@entry=true)
at ../../gcc/varasm.c:1143
#3  0x00acd8f0 in get_block_for_decl (decl=decl@entry=0x3ffaf6c1e60) at
../../gcc/varasm.c:1216
#4  0x00acf168 in make_decl_rtl (decl=decl@entry=0x3ffaf6c1e60) at
../../gcc/varasm.c:1471
#5  0x00acf788 in make_decl_rtl_for_debug
(decl=decl@entry=0x3ffaf6c1e60) at ../../gcc/varasm.c:1519
#6  0x00625b5c in rtl_for_decl_location (decl=decl@entry=0x3ffaf6c1e60)
at ../../gcc/dwarf2out.c:15950
#7  0x0064b518 in loc_list_from_tree (loc=loc@entry=0x3ffaf6c1e60,
want_address=2, context=context@entry=0x0)
at ../../gcc/dwarf2out.c:14579
#8  0x0064e450 in add_location_or_const_value_attribute(dw_die_ref,
tree, bool, enum dwarf_attribute) (die=0x3ffaf9b69f0, 
decl=0x3ffaf6c1e60, cache_p=cache_p@entry=false, attr=DW_AT_location) at
../../gcc/dwarf2out.c:16083
#9  0x006562a0 in dwarf2out_finish (filename=0x109d2d0 
"(\362", ) at ../../gcc/dwarf2out.c:24554
#10 0x008c7968 in compile_file () at ../../gcc/toplev.c:650
#11 0x00564ee8 in do_compile () at ../../gcc/toplev.c:2066
#12 toplev::main (this=0x0, this@entry=0x3fff080, argc=-1295660700,
argc@entry=52, argv=
0xd80101 ::do_get(int, int, int,
std::__cxx11::basic_string, std::allocator >
const&) const+17>, argv@entry=0x3fff1b8) at ../../gcc/toplev.c:2164
#13 0x005657f4 in main (argc=52, argv=0x3fff1b8) at
../../gcc/main.c:39

I.e. dwarf2out trying to compute RTL for a __PRETTY_FUNCTION__ VAR_DECL, but
has NULL lto_file_data.  The VAR_DECL is streamed in from LTO,
but without corresponding varpool node.  That node is added only during the
make_decl_rtl_for_debug call, so obviously it has NULL lto_file_data member and
varpool_node::get_constructor ICEs on it,
because it assumes it must be non-NULL.

So, either we change varpool_node::get_constructor, so that it treats
!lto_file_data the same as !in_lto_p.
Or tweak make_decl_rtl_for_debug to temporarily clear in_lto_p flag and restore
afterwards.
Or add another global flag which would tell us that we are called from
make_decl_rtl_for_debug and be more permissive in that case (i.e. bail out for
NULL lto_file_data).

Honza, your preference?

[Bug target/64793] [SH] missed delay slot

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64793

--- Comment #5 from Oleg Endo  ---
Author: olegendo
Date: Tue Feb 17 21:08:24 2015
New Revision: 220772

URL: https://gcc.gnu.org/viewcvs?rev=220772&root=gcc&view=rev
Log:
gcc/
PR target/64793
* config/sh/sh.md (cbranch define_delay): Set annulled true branch insn
to nil.  Adjust comments.

gcc/testsuite/
PR target/64793
* gcc.target/sh/pr64793.c: New.
* gcc.target/sh/pr51244-20-sh2a.c: Adjust expected cmp/gt insn count.

Added:
trunk/gcc/testsuite/gcc.target/sh/pr64793.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/sh/pr51244-20-sh2a.c

[Bug target/64793] [SH] missed delay slot

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64793

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Oleg Endo  ---
Fixed for GCC 5.

[Bug target/59375] internal compiler error: in expand_shift_1, at expmed.c:2245

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59375

Oleg Endo  changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e

--- Comment #8 from Oleg Endo  ---
Adrian, maybe you can provide some comments regarding this issue?

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028

--- Comment #26 from H.J. Lu  ---
(In reply to H.J. Lu from comment #24)
> (In reply to H.J. Lu from comment #18)
> > There are
> > 
> > ;; Function operator* (_ZmlRK10ggSpectrumS1_, funcdef_no=48, decl_uid=4292,
> > cgraph_uid=5, symbol_order=46520)
> > 
> > Modification phase of node operator*/46520
> >   Adjusting alignment of param 1 to 16, misalignment to 0
> 
> IPA-CP missed _ZN18eonImageCalculatorC1Ev which calls
> _ZmlRK10ggSpectrumS1_ with 8-byte aligned rPrimary.

We are using a clone:

Propagated alignment info for function _ZN18eonImageCalculatorC2Ev/50390:
  param 0: align: 16, misalign: 0

[Bug target/59375] internal compiler error: in expand_shift_1, at expmed.c:2245

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59375

--- Comment #9 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #8)
> Adrian, maybe you can provide some comments regarding this issue?

Well, yes. gcc-4.8 builds fine on native sh4 these days so it appears to have
been fixed.

Full build log of gcc-4.8.4, including a successful run of the testsuite:

> http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.8&arch=sh4&ver=4.8.4-1&stamp=1422178262

I think it's safe to close this bug.

PS: My new SSD is due to arrive to tomorrow. So I might have my sh4 up and
running tomorrow already, available for debugging.

Adrian

[Bug target/59375] internal compiler error: in expand_shift_1, at expmed.c:2245

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59375

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #10 from Oleg Endo  ---
Thanks.  I'm closing this PR then.

[Bug middle-end/62247] [5 Regression] FAIL: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62247

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P1  |P4
 CC||law at redhat dot com

--- Comment #8 from Jeffrey A. Law  ---
HPPA isn't a primary architecture, adjusting priority

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028

--- Comment #27 from H.J. Lu  ---
Created attachment 34794
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34794&action=edit
A patch

We should check all aliases for parameter alignments.

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028

--- Comment #28 from H.J. Lu  ---
(In reply to H.J. Lu from comment #26)
> (In reply to H.J. Lu from comment #24)
> > (In reply to H.J. Lu from comment #18)
> > > There are
> > > 
> > > ;; Function operator* (_ZmlRK10ggSpectrumS1_, funcdef_no=48, 
> > > decl_uid=4292,
> > > cgraph_uid=5, symbol_order=46520)
> > > 
> > > Modification phase of node operator*/46520
> > >   Adjusting alignment of param 1 to 16, misalignment to 0
> > 
> > IPA-CP missed _ZN18eonImageCalculatorC1Ev which calls
> > _ZmlRK10ggSpectrumS1_ with 8-byte aligned rPrimary.
> 
> We are using a clone:
> 
> Propagated alignment info for function _ZN18eonImageCalculatorC2Ev/50390:
>   param 0: align: 16, misalign: 0

I uploaded a patch to check all aliases for parameter alignments.  It
fixes eon on x32.

[Bug c/65096] New: Illegal memory access beyond packed struct ARCH: ppc64

[cyrilbur at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65096

Bug ID: 65096
   Summary: Illegal memory access beyond packed struct ARCH: ppc64
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cyrilbur at gmail dot com

Created attachment 34795
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34795&action=edit
Simple test case

When a heap allocated packed struct is passed by value and the struct contains
an array the copy gets performed with a sequence of ld instructions which can
cause the a read beyond the end of the struct.

In the case of the attached example: gcc uses ld instructions to copy the char
array if it is of size other than 1, 2 or 4. Therefore the assembly is only
correct if the size of the array is a multiple of 8 chars.

System information:

I am reliably informed that it reproduces on 5.0 but I have discovered it on a
system with the following versions.


builder:~ $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/4.8.3/lto-wrapper
Target: ppc64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-ppc64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-ppc64-redhat-linux/cloog-install
--enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC)

builder:~ $ valgrind --version
valgrind-3.8.1

To confirm:
Compile with `gcc gcc_test.c` and run the binary through valgrind `valgrind
./a.out`. Valgrind will report invalid read of size 8.


I have a attached a .i and also a simple example .c

Work arounds:
Pass the struct from the stack.

I have documented some of my debugging in the .c.

[Bug c/65096] Illegal memory access beyond packed struct ARCH: ppc64

[cyrilbur at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65096

--- Comment #1 from Cyril Bur  ---
Created attachment 34796
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34796&action=edit
Preprocessed version of the simple test case

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028

--- Comment #29 from H.J. Lu  ---
Created attachment 34797
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34797&action=edit
A reorg patch

This patch should be a no-op.  But it changes parameter
alignments for _ZmlRK10ggSpectrumS1_.  It looks like that
the behavior of -fipa-cp-alignment also depends on the
compiler sources.  There is a bug somewhere in
-fipa-cp-alignment implementation.

[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028

--- Comment #30 from Jan Hubicka  ---
> 
> I uploaded a patch to check all aliases for parameter alignments.  It
> fixes eon on x32.

Thanks for looking into this.  The bug is however a bit earlier. The
propagation
stage should never put anything into lattices of aliases (we probably should
add
checking assert that those are never used) and instead of that always go across
the alias into the final symbol.

I guess somewhere there is missing call to ultimate_alias_target (or
function_symbol)

Honza

[Bug tree-optimization/51017] GCC 4.6 performance regression (vs. 4.4/4.5), PRE increases register pressure

[solar-gcc at openwall dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51017

--- Comment #17 from Alexander Peslyak  ---
(In reply to Richard Biener from comment #16)
> I'm completely confused now as to what the original regression was reported
> against.

I'm sorry, I should have re-read my original description of the regression
before I wrote comment 13.  Together, these are indeed confusing.

> I thought it was the default options in the Makefile, -O2
> -fomit-frame-pointer, which showed the regression and you found -Os would
> mitigate it somewhat (and I more specifically told you it is -fno-tree-pre
> that makes the actual difference).

That's one of the regressions I mentioned in the original description.  Yes,
you identified -fno-tree-pre as the component of -Os that makes the difference
- Thank You!  However, I also mentioned in the original description that a
bigger regression with 4.6+ vs. 4.5 and 4.4 remained despite of -Os, and I had
no similar workaround for it at the time (but enabling -fopenmp made it go
away, perhaps due to changes to declarations in the source code in #ifdef
_OPENMP blocks).  I think we can now say that this bigger 4.6+ regression was
primarily caused by the unaligned load instructions.  So two regressions are
figured out, and the remaining slowdown (not investigated yet) vs. 4.1 to 4.3
(which worked best) is only 6% to 10% in recent versions (9% in 4.9.2).

> So - what options give good results with old compilers but bad results with
> new compilers?

On CPUs where movups/movdqu are slower than their aligned counterparts (for
addresses that happen to be aligned), any sane optimization options of 4.6+
give bad results as compared to pre-4.6 with same options.  As you say, this
can be fixed in the source code (and I most likely will fix it there), but I
think many other programs may experience similar slowdowns, so maybe GCC should
do something about this too.

Other than that, either -Os or -fno-tree-pre works around the second worst
slowdown seen in 4.6+.

To avoid confusion, maybe this bug should focus on one of the three
regressions?  Should we keep it for PRE only?

Should we create a new bug for the unnecessary and non-optional use of
unaligned load instructions for source code like this, or is this considered
the new intended behavior despite of the major slowdown on such CPUs? 
(Presumably not only for JtR.  I'd expect this to affect many programs.)

Should we also create a bug for investigating the remaining slowdown of 9% in
4.9.2 (vs. 4.1 to 4.3), or is it considered too minor to bother?

Thank you!

[Bug tree-optimization/51017] GCC 4.6 performance regression (vs. 4.4/4.5), PRE increases register pressure

[solar-gcc at openwall dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51017

--- Comment #18 from Alexander Peslyak  ---
(In reply to Richard Biener from comment #11)
> Note that we have to use movups because DES_bs_all is not aligned as seen
> from DES_bs_b.c (it's defined in DES_bs.c and only there annotated with
> CC_CACHE_ALIGN, not at the point of declaration in DES_bs.h).  So the
> unaligned moves are the sources fault.  Annotating that with CC_CACHE_ALIGN
> produces the desired movaps instructions

Confirmed also with GCC 4.9.2 on JtR 1.8.0's version of the code.

> (with no effect on performance for me).

... with the expected performance improvement for me.  I'll commit this fix. 
Thanks again!

[Bug tree-optimization/59124] [4.8/4.9/5 Regression] Wrong warnings "array subscript is above array bounds"

[solar-gcc at openwall dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124

Alexander Peslyak  changed:

   What|Removed |Added

 CC||solar-gcc at openwall dot com

--- Comment #8 from Alexander Peslyak  ---
Here's another testcase:

$ gcc -S -Wall -O2 -funroll-loops testcase.c 
testcase.c: In function 'DES_std_set_key':
testcase.c:14:17: warning: array subscript is above array bounds
[-Warray-bounds]
   while (DES_key[i++]) k += 2;
 ^

=== 8< ===
static int DES_KS_updates;
static char DES_key[16];

void DES_std_set_key(char *key)
{
int i, j, k, l;

j = key[0];
for (k = i = 0; (l = DES_key[i]) && (j = key[i]); i++)
;

if (!j) {
j = i;
while (DES_key[i++]) k += 2;
}

if (k < j && ++DES_KS_updates) {
}

DES_key[0] = key[0];
}
=== >8 ===

GCC 4.7.4 and below report no warning, 4.8.0 and 4.9.2 report the warning
above.  Either -O2 -funroll-loops or -O3 result in the warning; simple -O2 does
not.  While i++ could potentially run beyond the end of DES_key[], depending on
what's in DES_key[] and key[], this isn't the case in the program this snippet
is taken from (and simplified), whereas the warning definitively claims "is"
rather than "might be".

For comparison, Dmitry's first testcase (from this bug's description) results
in no warning with -O2 -funroll-loops (but does give the warning to me with
-O3, as reported by Dmitry), whereas his second testcase (from comment 2) also
reports the warning with -O2 -funroll-loops (but not with simple -O2).  I
tested this with 4.9.2.

I hope this is similar enough to add to this bug (same affected versions, one
of the two testcases also affected by -funroll-loops).

[Bug middle-end/62247] [5 Regression] FAIL: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62247

--- Comment #9 from dave.anglin at bell dot net ---
On 2015-02-17, at 5:16 PM, law at redhat dot com wrote:

> HPPA isn't a primary architecture, adjusting priority

Why?  P1 was set by Richard, a release maintainer, and the regression was
introduced by an identified
two line change.  There hasn't been any comment from Jason on the matter, so I
don't know if there's
anything I can do to resolve the bug.

Weak support is important for c++ support and it seems unfair to downgrade to
what is essentially WONTFIX.

I understand that HPPA shouldn't block release, but many others have worked to
resolve bugs affecting HPPA.

At this point, we don't even know if this is simply a testsuite issue or not.

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

[Bug tree-optimization/51017] GCC 4.6 performance regression (vs. 4.4/4.5), PRE increases register pressure

[solar-gcc at openwall dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51017

--- Comment #19 from Alexander Peslyak  ---
(In reply to Alexander Peslyak from comment #17)
> Should we create a new bug for the unnecessary and non-optional use of
> unaligned load instructions for source code like this, or is this considered
> the new intended behavior despite of the major slowdown on such CPUs? 
> (Presumably not only for JtR.  I'd expect this to affect many programs.)

Upon further analysis, I now think that this was my fault, and (presumably) not
common in other programs.  What I had was differing definition vs. declaration,
so a bug.  The lack of alignment specification in the declaration of the struct
essentially told (newer) GCC not to assume alignment - to an extent greater
than e.g. a pointer would.  As far as I can tell, GCC does not currently
produce unaligned load instructions (so assumes that SSE* vectors are properly
aligned) when all it has is a pointer coming from another object file.  I think
that's the common scenario, whereas mine was uncommon (and incorrect).

So let's focus on PRE only.

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #21 from Jerry DeLisle  ---
Created attachment 34798
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34798&action=edit
Full Patch

This patch attempts to do it all. I have not tested the mingw/cygwin side of
it.

Any testing/comments welcome

[Bug tree-optimization/59124] [4.8/4.9/5 Regression] Wrong warnings "array subscript is above array bounds"

[solar-gcc at openwall dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124

--- Comment #9 from Alexander Peslyak  ---
(In reply to Alexander Peslyak from comment #8)
> $ gcc -S -Wall -O2 -funroll-loops testcase.c 
> testcase.c: In function 'DES_std_set_key':
> testcase.c:14:17: warning: array subscript is above array bounds

With GCC 5.0.0 20150215, this warning is gone.  I also confirm that Dmitry's
comment #2 warning is gone.  The original one from this bug's description
remains.