[Bug tree-optimization/78413] [7 Regression] ICE in single_pred_edge, at basic-block.h:361

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
Test case #1 seems to go wrong sometime between revision 242538 and
revision 242583

[Bug other/78410] gen-fac.c: undefined references

[neotheuser at ymail dot com]

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

Alec Ari  changed:

   What|Removed |Added

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

--- Comment #2 from Alec Ari  ---
Will switch to GLIBC, thank you!

[Bug tree-optimization/78413] [7 Regression] ICE in single_pred_edge, at basic-block.h:361

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Another testcase

markus@x4 /tmp % cat test2.i
struct S {
  _Bool bo;
};
int a, b, c, d;
void fn1() {
  do
do
  do {
struct S *e = (struct S *)1;
do
  b = a / (e->bo ? 2 : 1);
while (b);
  } while (0);
while (d);
  while (c);
}

markus@x4 /tmp % gcc -O3 -fno-strict-aliasing -c test2.i
test2.i: In function ‘fn1’:
test2.i:5:6: internal compiler error: in single_pred_edge, at basic-block.h:361

[Bug tree-optimization/78413] New: [7 Regression] ICE in single_pred_edge, at basic-block.h:361

[trippels at gcc dot gnu.org]

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

Bug ID: 78413
   Summary: [7 Regression] ICE in single_pred_edge, at
basic-block.h:361
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: wschmidt at gcc dot gnu.org
  Target Milestone: ---

markus@x4 /tmp % cat test.i
extern long long int llrint(double x);
int a;
double b;
__attribute__((cold)) void decode_init() {
  int c, d = 0;
  for (; d < 12; d++) {
if (d)
  b = 0;
c = 0;
for (; c < 6; c++)
  a = b ? llrint(b) : 0;
  }
}

markus@x4 /tmp % gcc -O3 -ffast-math -c test.i
test.i: In function ‘decode_init’:
test.i:4:28: internal compiler error: in single_pred_edge, at basic-block.h:361
 __attribute__((cold)) void decode_init() {
^~~
0x5a4ea1 single_pred_edge
../../gcc/gcc/basic-block.h:361
0xbed2bf single_pred
../../gcc/gcc/basic-block.h:380
0xbed2bf versionable_outer_loop_p
../../gcc/gcc/tree-if-conv.c:2592
0xbed2bf tree_if_conversion(loop*)
../../gcc/gcc/tree-if-conv.c:2813
0xbed611 execute
../../gcc/gcc/tree-if-conv.c:2893

[Bug middle-end/72747] powerpc: wrong code generated for vec_splats in cascading assignment

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||npmccallum at redhat dot com

--- Comment #6 from Markus Trippelsdorf  ---
*** Bug 78408 has been marked as a duplicate of this bug. ***

[Bug c/78408] C loop initial declarations generate wrong code

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #8 from Markus Trippelsdorf  ---
(In reply to jos...@codesourcery.com from comment #7)
> I can't reproduce this with recent GCC 6 branch.  Possibly a duplicate of 
> bug 72747?

Yes.

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

[Bug tree-optimization/78394] False positives of maybe-uninitialized with -Og

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||24639

--- Comment #3 from Andrew Pinski  ---
There might be a dup of this bug already.  See the linked PR if there is one.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug c++/78391] g++ (any version) at O0 (for O1, O2, O3 is ok) doesn't warn when class members are used uninitialized.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||24639

--- Comment #3 from Andrew Pinski  ---
There might be a dup of this bug already.  Linking against the meta-bug about
uninit warnings.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug libgcc/78409] Segfault in classify_object_over_fdes when throwing and exception

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
We need a testcase.

[Bug other/78410] gen-fac.c: undefined references

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>I've already built binutils and newlib

You are building gcc against newlib; that is broken.

[Bug target/78002] gcc.target/aarch64/stack-checking.c ICEs with -mabi=ilp32

[hs.naveen2u at gmail dot com]

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

hs.naveen2u at gmail dot com changed:

   What|Removed |Added

 CC||hs.naveen2u at gmail dot com

--- Comment #2 from hs.naveen2u at gmail dot com ---
Could not reproduce the issue on latest FSF source:-

Tried using the following command:-
-gcc -fstack-check gcc/testsuite/gcc.target/aarch64/stack-checking.c 
-mabi=ilp32

[Bug libfortran/78379] Processor-specific versions for matmul

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #6)
> > You may notice I was invoking the wrong executable in what I posted in
> > comment #3. I did rerun the correct one several times and tried it with
> > -mavx -mprefer-avx128. I get the same poor results regardless.
> 
> Several things could go wrong here...
> 
> If you run the benchmark under gdb and break, then type
> "disassemble $pc,$pc+200", do you actually end up in the right
> program part (the one with AVX instructions)?

452   f32 += t1[l - ll + 1 + ((i - ii + 3) <<
8) - 257]
(gdb) disassemble $pc,$pc+200
Dump of assembler code from 0x77af3554 to 0x77af361c:
=> 0x77af3554 : vaddpd %ymm12,%ymm4,%ymm4
   0x77af3559 : vmulpd %ymm10,%ymm15,%ymm12
   0x77af355e : vaddpd %ymm11,%ymm5,%ymm5
   0x77af3563 : vmulpd %ymm14,%ymm15,%ymm15
   0x77af3568 : vmulpd %ymm10,%ymm13,%ymm10
   0x77af356d : vaddpd %ymm12,%ymm6,%ymm6
   0x77af3572 : vmulpd %ymm14,%ymm13,%ymm14
   0x77af3577 : vaddpd %ymm15,%ymm8,%ymm8
   0x77af357c : vaddpd %ymm10,%ymm7,%ymm7
   0x77af3581 : vaddpd %ymm14,%ymm9,%ymm9
   0x77af3586 : ja 0x77af3433

   0x77af358c : mov-0x801f8(%rbp),%rdx
   0x77af3593 : vhaddpd %ymm9,%ymm9,%ymm13
   0x77af3598 : vhaddpd %ymm8,%ymm8,%ymm15
   0x77af359d : vhaddpd %ymm7,%ymm7,%ymm7
   0x77af35a1 : vperm2f128
$0x1,%ymm13,%ymm13,%ymm11
   0x77af35a7 : vhaddpd %ymm5,%ymm5,%ymm5
   0x77af35ab : vperm2f128
$0x1,%ymm15,%ymm15,%ymm8
   0x77af35b1 : vaddpd %ymm11,%ymm13,%ymm12
   0x77af35b6 : vperm2f128
$0x1,%ymm7,%ymm7,%ymm13
   0x77af35bc : vaddpd %ymm8,%ymm15,%ymm14
   0x77af35c1 : vhaddpd %ymm6,%ymm6,%ymm6
---Type  to continue, or q  to quit---
   0x77af35c5 : vaddsd
-0x80068(%rbp),%xmm12,%xmm10
   0x77af35cd : vaddsd
-0x80070(%rbp),%xmm14,%xmm9
   0x77af35d5 : vperm2f128
$0x1,%ymm5,%ymm5,%ymm14
   0x77af35db : vhaddpd %ymm4,%ymm4,%ymm4
   0x77af35df : vaddpd %ymm13,%ymm7,%ymm11
   0x77af35e4 : vmovsd %xmm10,-0x80068(%rbp)
   0x77af35ec : vperm2f128
$0x1,%ymm6,%ymm6,%ymm10
   0x77af35f2 : vperm2f128
$0x1,%ymm4,%ymm4,%ymm13
   0x77af35f8 : vmovsd %xmm9,-0x80070(%rbp)
   0x77af3600 : vaddpd %ymm14,%ymm5,%ymm9
   0x77af3605 : vhaddpd %ymm0,%ymm0,%ymm0
   0x77af3609 : vaddsd
-0x80058(%rbp),%xmm11,%xmm12
   0x77af3611 : vaddpd %ymm10,%ymm6,%ymm15
   0x77af3616 : vaddpd %ymm13,%ymm4,%ymm11
   0x77af361b : vperm2f128
$0x1,%ymm0,%ymm0,%ymm13
End of assembler dump.



> 
> Or does your machine prefer AVX128?
> 
> To find out, what are the timings for inline code using
> 
> -mavx -Ofast
> 
> -mavx -mprefer=avx128 -Ofast
> 
> ?
$ gfc  -finline-matmul-limit=64 -Ofast compare.f90
$ ./a.out 
 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  2000  4.933  0.045  0.086  0.144
4  2000  1.418  0.225  0.271  0.347
8  2000  2.168  0.616  1.296  1.830
   16  2000  5.330  2.824  1.784  2.907
   32  2000  6.239  3.488  1.446  3.406
   64  2000  2.650  2.746  1.552  2.691

$ gfc  -finline-matmul-limit=64 -mavx -Ofast compare.f90
$ ./a.out 
 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed

[Bug ipa/78296] [7 regression] test case gcc.dg/ipa/vrp7.c fails starting with r242032

[kugan at gcc dot gnu.org]

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

kugan at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from kugan at gcc dot gnu.org ---
Fixed with r242368.

[Bug c/78365] [7 Regression] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

[kugan at gcc dot gnu.org]

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

--- Comment #6 from kugan at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
> IPA has to deal with argument mismatches (I think I've said this elsewhere).

As I understand, this is along what you found earlier but a different issue. I
posted a patch at https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01878.html for
review.

[Bug middle-end/38219] gcc.dg/tree-ssa/vrp47.c fails on m68k

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #20 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug middle-end/38219] gcc.dg/tree-ssa/vrp47.c fails on m68k

[law at gcc dot gnu.org]

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

--- Comment #19 from Jeffrey A. Law  ---
Author: law
Date: Thu Nov 17 23:54:46 2016
New Revision: 242576

URL: https://gcc.gnu.org/viewcvs?rev=242576=gcc=rev
Log:
PR middle-end/38219
* gcc.dg/tree-ssa/vrp47.c: Do not run on m68k.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp47.c

[Bug target/47192] m68k target - gcc uses stack frame after it has been unlinked when compiling with -Os

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #4 from Jeffrey A. Law  ---
Fixed with commit on the trunk.

[Bug target/47192] m68k target - gcc uses stack frame after it has been unlinked when compiling with -Os

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Thu Nov 17 23:39:08 2016
New Revision: 242575

URL: https://gcc.gnu.org/viewcvs?rev=242575=gcc=rev
Log:
PR target/47192
* config/m68k/m68k.c (m68k_expand_epilogue): Emit a scheduling
barrier prior to deallocating the stack.

PR target/47192
* gcc.target/m68k/pr47192.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/m68k/pr47192.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/m68k/m68k.c
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/78379] Processor-specific versions for matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
And one more thing.

Comparing the timing you get for the version with the target_clone
and a version using just -mavx added to the relevant line in the
Makefile, do you see a difference?

[Bug libfortran/78379] Processor-specific versions for matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---

> You may notice I was invoking the wrong executable in what I posted in
> comment #3. I did rerun the correct one several times and tried it with
> -mavx -mprefer-avx128. I get the same poor results regardless.

Several things could go wrong here...

If you run the benchmark under gdb and break, then type
"disassemble $pc,$pc+200", do you actually end up in the right
program part (the one with AVX instructions)?

Or does your machine prefer AVX128?

To find out, what are the timings for inline code using

-mavx -Ofast

-mavx -mprefer=avx128 -Ofast

?

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

[jvdelisle at gcc dot gnu.org]

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

--- Comment #21 from Jerry DeLisle  ---
(In reply to Steve Kargl from comment #19)
> On Thu, Nov 17, 2016 at 12:43:40AM +, kevin.b.beard at nasa dot gov
> wrote:
> > Many thanks to Jerry DeLisle [jvdeli...@charter.net]; he made us realize
> > that an internal record is now not treated the same as an external record!
> 
> Ugh.  It ought to be treated the same.
> 

Working on it. In read_sf we have this:

  /*  Short circuit the read if a comma is found during numeric input.
  The flag is set to zero during character reads so that commas in
  strings are not ignored  */
  else if (q == ',')
if (dtp->u.p.sf_read_comma == 1)
  {
seen_comma = 1;
notify_std (>common, GFC_STD_GNU,
"Comma in formatted numeric read.");
break;
  }

and it does give an error when using -std=f95. No such code for
read_internal_sf.

[Bug target/47192] m68k target - gcc uses stack frame after it has been unlinked when compiling with -Os

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-17
 Ever confirmed|0   |1

--- Comment #2 from Jeffrey A. Law  ---
This is latent on the trunk, but that's only because the trunk IPA analysis has
gotten stronger and as a result it eventually is able to get rid of the
assignment that was sunk after the stack deallocation.

THe standard way to fix this is to emit scheduling barriers before cutting back
the stack in the epilogue.  I'll take care of it.

[Bug libfortran/78379] Processor-specific versions for matmul

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
(In reply to Uroš Bizjak from comment #4)
> (In reply to Jerry DeLisle from comment #3)
> > I did apply your second patch:
> > 
> > I do not get any improvement and results are diminished from current trunk,
> > so I am missing something. This is same machine I used showing results in
> > 51119. It does have avx.
> 
> You have AMD processor, can you try with -mprefer-avx128 option?

You may notice I was invoking the wrong executable in what I posted in comment
#3. I did rerun the correct one several times and tried it with -mavx
-mprefer-avx128. I get the same poor results regardless.

[Bug c++/78193] [7 regression] g++.dg/concepts/inherit-ctor3.C etc. FAIL at r241765

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Thu Nov 17 22:40:28 2016
New Revision: 242573

URL: https://gcc.gnu.org/viewcvs?rev=242573=gcc=rev
Log:
PR c++/78193 - inherited ctor regressions on sparc32.

* call.c (build_over_call): Don't set CALL_FROM_THUNK_P here.
(build_call_a): Set it here, and don't insert EMPTY_CLASS_EXPR.
(convert_like_real) [ck_rvalue]: Also pass non-addressable
types along directly.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c++/78193] [7 regression] g++.dg/concepts/inherit-ctor3.C etc. FAIL at r241765

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/68377] [c++17] unary right fold fails to compile

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |6.3

--- Comment #8 from Jason Merrill  ---
Fixed for 6.3/7.

[Bug c++/68377] [c++17] unary right fold fails to compile

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Thu Nov 17 22:27:56 2016
New Revision: 242571

URL: https://gcc.gnu.org/viewcvs?rev=242571=gcc=rev
Log:
PR c++/68377 - parenthesized expr in fold-expression

* parser.c (cp_parser_fold_expression): Check TREE_NO_WARNING.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1z/fold8.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/parser.c

[Bug c++/78193] [7 regression] g++.dg/concepts/inherit-ctor3.C etc. FAIL at r241765

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/20641] Missed optimization on the tree level (malloc attribute)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78412

--- Comment #3 from Martin Sebor  ---
To be clear, a test case that shows the effect of attribute malloc is one where
the variable is extern, like below.  (For the record, I got here by trying to
devise a test case for the attribute and having  trouble with it as noted in
bug 78412).

$ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout x.c
extern int* f0 (void);
extern int* __attribute__ ((malloc)) f1 (void);

extern int x;

void g0 (void)
{
  int *p = 
  int *q = f0 ();

  *p = 12;
  *q = 8;

  if (*p != 12)  __builtin_abort ();
}

void g1 (void)
{
  int *p = 
  int *q = f1 ();

  *p = 12;
  *q = 8;

  if (*p != 12)  __builtin_abort ();
}


;; Function g0 (g0, funcdef_no=0, decl_uid=1800, cgraph_uid=0, symbol_order=0)

g0 ()
{
  int * q;
  int _1;

  :
  q_4 = f0 ();
  x = 12;
  *q_4 = 8;
  _1 = x;
  if (_1 != 12)
goto ;
  else
goto ;

  :
  __builtin_abort ();

  :
  return;

}



;; Function g1 (g1, funcdef_no=1, decl_uid=1805, cgraph_uid=1, symbol_order=1)

g1 ()
{
  :
  f1 ();
  x = 12;
  return;

}

[Bug tree-optimization/20641] Missed optimization on the tree level (malloc attribute)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
The test case in comment #0 is optimized as expected but not because of
attribute malloc but rather because x is static and function f is not defined
in the same translation unit, meaning it can't access x.  The test case is
optimized on this basis even without attribute malloc:

$ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout x.c
extern int* f (void);

static int x;

void g (void)
{
  int *p = 
  int *q = f ();

  *p = 12;
  *q = 8;

  if (*p != 12)  __builtin_abort ();
}

;; Function g (g, funcdef_no=0, decl_uid=1798, cgraph_uid=0, symbol_order=1)

g ()
{
  int * q;

  :
  q_4 = f ();
  x = 12;
  *q_4 = 8;
  return;

}

[Bug c++/55080] -pedantic produces error: floating-point literal cannot appear in a constant-expression

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #6 from Paolo Carlini  ---
Fixed.

[Bug c++/78369] [7 Regression] default parameter ICEs

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/55080] -pedantic produces error: floating-point literal cannot appear in a constant-expression

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Nov 17 21:44:05 2016
New Revision: 242565

URL: https://gcc.gnu.org/viewcvs?rev=242565=gcc=rev
Log:
/cp
2016-11-17  Paolo Carlini  

PR c++/55080
* parser.c (cp_parser_non_integral_constant_expression): Issue a
pedwarn instead of an error for case NIC_FLOAT.

/testsuite
2016-11-17  Paolo Carlini  

PR c++/55080
* g++.dg/parse/pr55080.C: New.

Added:
trunk/gcc/testsuite/g++.dg/parse/pr55080.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/78124] [7 regression][c++1z] explicit inheriting constructor is ignored

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug target/78101] PowerPC 64-bit little endian fusion failure with -O3 -mcpu=power9

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Thu Nov 17 21:42:13 2016
New Revision: 242564

URL: https://gcc.gnu.org/viewcvs?rev=242564=gcc=rev
Log:
[gcc]
2016-11-17  Michael Meissner  

PR target/78101
* config/rs6000/predicates.md (fusion_addis_mem_combo_load): Add
the appropriate checks for SFmode/DFmode load/stores in GPR
registers.
(fusion_addis_mem_combo_store): Likewise.
* config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): Rename
fusion_fpr_* to fusion_vsx_* and add in support for ISA 3.0 scalar
d-form instructions for traditional Altivec registers.
(emit_fusion_p9_load): Likewise.
(emit_fusion_p9_store): Likewise.
* config/rs6000/rs6000.md (p9 fusion store peephole2): Remove
early clobber from scratch register.  Do not match if the register
being stored is the scratch register.
(fusion_vsx___load): Rename fusion_fpr_*
to fusion_vsx_* and add in support for ISA 3.0 scalar d-form
instructions for traditional Altivec registers.
(fusion_fpr___load): Likewise.
(fusion_vsx___store): Likewise.
(fusion_fpr___store): Likewise.

[gcc/testsuite]
2016-11-17  Michael Meissner  

PR target/78101
* gcc.target/powerpc/fusion4.c: New test.


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

[Bug c++/78124] [7 regression][c++1z] explicit inheriting constructor is ignored

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Thu Nov 17 21:41:09 2016
New Revision: 242563

URL: https://gcc.gnu.org/viewcvs?rev=242563=gcc=rev
Log:
PR c++/78124 - list-initialization and inherited ctor

* name-lookup.c (do_class_using_decl): Set CLASSTYPE_NON_AGGREGATE.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor23.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/name-lookup.c

[Bug c++/78369] [7 Regression] default parameter ICEs

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Nov 17 21:40:48 2016
New Revision: 242562

URL: https://gcc.gnu.org/viewcvs?rev=242562=gcc=rev
Log:
PR c++/78369 - {} as default argument

* call.c (build_special_member_call): Handle CONSTRUCTOR.

Added:
trunk/gcc/testsuite/g++.dg/overload/defarg11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c++/68377] [c++17] unary right fold fails to compile

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Thu Nov 17 21:40:41 2016
New Revision: 242561

URL: https://gcc.gnu.org/viewcvs?rev=242561=gcc=rev
Log:
PR c++/68377 - parenthesized expr in fold-expression

* parser.c (cp_parser_fold_expression): Check TREE_NO_WARNING.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/fold8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug middle-end/78412] New: attribute malloc ineffective

[msebor at gcc dot gnu.org]

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

Bug ID: 78412
   Summary: attribute malloc ineffective
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

I came across this while testing my patch for bug 78284
(https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01672.html) where I accidentally
removed attribute malloc from one of the built-ins.

Attribute malloc is document to have the effect that...

...the pointer P returned by the function cannot alias any other pointer valid
when the function returns, and moreover no pointers to valid objects occur in
any storage addressed by P.

Given this, I would expect the calls to abort to be eliminated in all the
functions below except g() because in all of them the non-null pointers
returned from successive calls to function f1 must be distinct from one another
and cannot point into the storage returned by the malloc-like function.  Yet
GCC retains all of them.

void* f0 (unsigned);
void* __attribute__ ((malloc)) f1 (unsigned);

void g0 (void)
{
  void *p = f0 (sizeof (void*));
  void *q = f0 (sizeof (void*));

  if (p && p == q) __builtin_abort ();   // expect to be retained
}

void g1 (void)
{
  void *p = f1 (sizeof (void*));
  void *q = f1 (sizeof (void*));

  if (p && p == q) __builtin_abort ();   // expected to be optimized away
}

void g2 (void)
{
  void *p = f1 (sizeof (void*));
  void *q = f1 (sizeof (void*));

  if (p && q && *(void**)q == p) __builtin_abort ();   // expected to be
optimized away
}

void g3 (void)
{
  void *p = __builtin_malloc (sizeof (void*));
  void *q = __builtin_malloc (sizeof (void*));

  if (p && p == q) __builtin_abort ();   // expected to be optimized away
}

[Bug c/78408] C loop initial declarations generate wrong code

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com  ---
I can't reproduce this with recent GCC 6 branch.  Possibly a duplicate of 
bug 72747?

[Bug c/78408] C loop initial declarations generate wrong code

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
I don't think this is related to the loop, a = b = (struct buf) {} loses the
assignment to b even if you put it alone on its line.

[Bug c/78408] C loop initial declarations generate wrong code

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

Summary|Aggressive optimization of  |C loop initial declarations
   |zeroing results in  |generate wrong code
   |incorrect behavior  |

--- Comment #5 from Markus Trippelsdorf  ---
This has nothing to do with "aggressive optimization" it is a bug in C
front-end, I guess in the "loop initial declarations" implementation.

[Bug tree-optimization/77673] [5/6/7 Regression] 4-byte load generated instead of 1-byte load, possibly reading past the end of object

[thopre01 at gcc dot gnu.org]

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

--- Comment #5 from Thomas Preud'homme  ---
Got a patch, testing it now.

[Bug c/78408] Aggressive optimization of zeroing results in incorrect behavior

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-17
 CC||trippels at gcc dot gnu.org
  Known to work||7.0
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.2.1

--- Comment #4 from Markus Trippelsdorf  ---
Confirmed. Trunk is fine.

--- good2016-11-17 21:45:22.671247332 +0100
+++ bad 2016-11-17 21:45:18.851324283 +0100
@@ -58,11 +58,6 @@
callwrite
testq   %rax, %rax
jle .L10
-   leaq-65536(%rbp), %rax
-   movl$65520, %edx
-   movl$0, %esi
-   movq%rax, %rdi
-   callmemset
leaq-131056(%rbp), %rax
leaq-65536(%rbp), %rcx
movl$65520, %edx
@@ -86,5 +81,5 @@
.cfi_endproc
 .LFE0:
.size   main, .-main
-   .ident  "GCC: (GNU) 7.0.0 20161117 (experimental)"
+   .ident  "GCC: (GNU) 6.2.1 20161017"
.section.note.GNU-stack,"",@progbits

[Bug c++/78369] [7 Regression] default parameter ICEs

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug middle-end/78411] New: FAIL: gcc.target/i386/pr45685.c scan-assembler-times cmov 6

[msebor at gcc dot gnu.org]

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

Bug ID: 78411
   Summary: FAIL: gcc.target/i386/pr45685.c scan-assembler-times
cmov 6
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The gcc.target/i386/pr45685.c fails on x86_64:
  https://gcc.gnu.org/ml/gcc-testresults/2016-11/msg01936.html

The first recent mention of the failure I was able to find in the
gcc-regression archives is here:
  https://gcc.gnu.org/ml/gcc-regression/2015-11/msg00320.html

[Bug target/77933] Stack corruption on ARM when using high registers and __builtin_return_address

[thopre01 at gcc dot gnu.org]

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

--- Comment #6 from Thomas Preud'homme  ---
Author: thopre01
Date: Thu Nov 17 20:30:41 2016
New Revision: 242560

URL: https://gcc.gnu.org/viewcvs?rev=242560=gcc=rev
Log:
Fix PR77933: stack corruption on ARM when using high registers and LR

2016-11-08  Thomas Preud'homme  

Backport from mainline
2016-11-08  Thomas Preud'homme  

gcc/
PR target/77933
* config/arm/arm.c (thumb1_expand_prologue): Distinguish between lr
being live in the function and lr needing to be saved.  Distinguish
between already saved pushable registers and registers to push.
Check for LR being an available pushable register.

gcc/testsuite/
PR target/77933
* gcc.target/arm/pr77933-1.c: New test.
* gcc.target/arm/pr77933-2.c: Likewise.


Added:
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.target/arm/pr77933-1.c
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.target/arm/pr77933-2.c
Modified:
branches/ARM/embedded-6-branch/gcc/ChangeLog.arm
branches/ARM/embedded-6-branch/gcc/config/arm/arm.c
branches/ARM/embedded-6-branch/gcc/testsuite/ChangeLog.arm

[Bug c/78408] Aggressive optimization of zeroing results in incorrect behavior

[npmccallum at redhat dot com]

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

--- Comment #3 from Nathaniel McCallum  ---
Created attachment 40077
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40077=edit
output assembly from the test case

This assembly was produced with: gcc -S test.c.

[Bug c/78408] Aggressive optimization of zeroing results in incorrect behavior

[npmccallum at redhat dot com]

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

--- Comment #2 from Nathaniel McCallum  ---
Created attachment 40076
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40076=edit
simple test case

Compile with: gcc -o test test.c

This is a simple echo server. It *should* echo whatever the client types. 
However, if you type "foo" the first time and then type ctrl-d the second time,
the second reply is the same as the first reply. This is because the buffer was
not properly zeroed.

[Bug other/78410] New: gen-fac.c: undefined references

[neotheuser at ymail dot com]

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

Bug ID: 78410
   Summary: gen-fac.c: undefined references
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neotheuser at ymail dot com
  Target Milestone: ---

Created attachment 40075
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40075=edit
build error

Hello, I'm trying to build a complete native toolchain into a custom directory
(not /usr) similar to what crosstool-ng does. I've already built binutils and
newlib, now just trying to build the first pass GCC compiler, this is my
configure line for GCC:

mkdir -p build && cd build && ../configure --with-newlib --without-headers
--target=x86_64-pc-linux-gnu --prefix=/home//git-toolchain-bin
--disable-nls --disable-shared --disable-multilib --disable-decimal-float
--disable-threads --disable-libatomic --disable-libgomp --disable-libmpx
--disable-libquadmath --disable-libssp --disable-libvtv --disable-libstdcxx
--enable-languages=c --disable-lto --with-system-zlib --disable-werror
--disable-gold --without-isl
--with-native-system-header-dir=/home//git-toolchain-bin/include
--disable-libcilkrts --disable-libitm --disable-libsanitizer
--with-local-prefix=/home//git-toolchain-bin

The following error is attached. Any help and suggestions would be great!

Alec Ari

[Bug libfortran/78379] Processor-specific versions for matmul

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Jerry DeLisle from comment #3)
> I did apply your second patch:
> 
> I do not get any improvement and results are diminished from current trunk,
> so I am missing something. This is same machine I used showing results in
> 51119. It does have avx.

You have AMD processor, can you try with -mprefer-avx128 option?

[Bug target/77933] Stack corruption on ARM when using high registers and __builtin_return_address

[thopre01 at gcc dot gnu.org]

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

--- Comment #5 from Thomas Preud'homme  ---
Author: thopre01
Date: Thu Nov 17 20:12:13 2016
New Revision: 242559

URL: https://gcc.gnu.org/viewcvs?rev=242559=gcc=rev
Log:
Fix PR77933: stack corruption on ARM when using high registers and LR

2016-11-17  Thomas Preud'homme  

gcc/
PR target/77933
* config/arm/arm.c (thumb1_expand_prologue): Distinguish between lr
being live in the function and lr needing to be saved.  Distinguish
between already saved pushable registers and registers to push.
Check for LR being an available pushable register.

gcc/testsuite/
PR target/77933
* gcc.target/arm/pr77933-1.c: New test.
* gcc.target/arm/pr77933-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr77933-1.c
trunk/gcc/testsuite/gcc.target/arm/pr77933-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/78379] Processor-specific versions for matmul

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
I did apply your second patch:

I do not get any improvement and results are diminished from current trunk, so
I am missing something. This is same machine I used showing results in 51119.
It does have avx.

flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf
eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave
avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse
3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext
perfctr_core perfctr_nb cpb hw_pstate vmmcall bmi1 arat npt lbrv svm_lock
nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter
pfthreshold

$ gfc -static-libgfortran -finline-matmul-limit=0 -Ofast -o compare_mavx
compare.f90
$ ./a.out 
 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  2000  5.043  0.045  0.091  0.150
4  2000  1.417  0.235  0.353  0.325
8  2000  2.016  0.634  0.862  2.021
   16  2000  5.332  2.834  2.239  2.929
   32  2000  6.169  3.496  1.931  3.289
   64  2000  2.656  2.836  2.655  2.657
  128  2000  2.898  3.286  2.901  2.901
  256   477  3.157  3.429  3.156  3.157
  51259  3.082  2.356  3.133  3.126
 1024 7  3.102  1.363  3.144  3.136
 2048 1  3.099  1.685  3.144  3.140

[Bug c/78408] Aggressive optimization of zeroing results in incorrect behavior

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Do you think you could produce a smaller, stand-alone testcase that reproduces
the issue? Or at least attach the preprocessed sources to the report?

[Bug tree-optimization/69270] DOM should exploit range information to create more equivalences

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=72850

--- Comment #7 from Martin Sebor  ---
The test failure is being tracked in bug 72850.

[Bug ada/48835] porting GNAT to m68k-linux

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #59 from Jeffrey A. Law  ---
All the issues in this BZ should be addressed on the trunk.  Any further GNAT
problems on m68k should be tracked with a new BZ.

Let's avoid mega-bugs like this in the future -- instead track each distinct
problem as a distinct bug so that it's relatively easy to know the state of a
given issue.

When many bugs are blocking a single larger issue (like we've seen with this
BZ), open a bug for the large issue and make it dependent upon the individual
bugs.

[Bug libgcc/78409] New: Segfault in classify_object_over_fdes when throwing and exception

[orion at cora dot nwra.com]

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

Bug ID: 78409
   Summary: Segfault in classify_object_over_fdes when throwing
and exception
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: orion at cora dot nwra.com
  Target Milestone: ---

Running on Fedora rawhide with gcc-6.2.1-2.fc26

Core was generated by
`/home/orion/fedora/octave/octave-4.2.0/src/.libs/lt-octave-gui --no-init-path
-'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  classify_object_over_fdes (ob=ob@entry=0x7f3a4d3d4910,
this_fde=0x7f3a6f220018)
at ../../../libgcc/unwind-dw2-fde.c:613
613   for (; ! last_fde (ob, this_fde); this_fde = next_fde (this_fde))
(gdb) print ob
$1 = (struct object *) 0x7f3a4d3d4910
(gdb) print this_fde
$2 = (const fde *) 0x7f3a6f220018
(gdb) print *this_fde
Cannot access memory at address 0x7f3a6f220018
(gdb) print *ob
$3 = {pc_begin = 0x, tbase = 0x0, dbase = 0x0, u = {single =
0x7f3a6f220018,
array = 0x7f3a6f220018, sort = 0x7f3a6f220018}, s = {b = {sorted = 0,
from_array = 0,
  mixed_encoding = 0, encoding = 255, count = 0}, i = 2040}, next =
0x7f3a4d3c3580}
(gdb) print *(fde *)0x7f3a6f220018
Cannot access memory at address 0x7f3a6f220018

(gdb) bt
#0  0x7f3a6ba7235e in classify_object_over_fdes
(ob=ob@entry=0x7f3a4d3d4910, this_fde=0x7f3a6f220018) at
../../../libgcc/unwind-dw2-fde.c:613
#1  0x7f3a6ba72859 in init_object (ob=0x7f3a4d3d4910)
at ../../../libgcc/unwind-dw2-fde.c:749
#2  0x7f3a6ba72859 in search_object (ob=ob@entry=0x7f3a4d3d4910,
pc=pc@entry=0x7f3a6ba7125d <_Unwind_RaiseException+61>) at
../../../libgcc/unwind-dw2-fde.c:961
#3  0x7f3a6ba730f6 in _Unwind_Find_registered_FDE (bases=0x7f3a516fd2c8,
pc=0x7f3a6ba7125d <_Unwind_RaiseException+61>) at
../../../libgcc/unwind-dw2-fde.c:1025
#4  0x7f3a6ba730f6 in _Unwind_Find_FDE (pc=0x7f3a6ba7125d
<_Unwind_RaiseException+61>, bases=bases@entry=0x7f3a516fd2c8) at
../../../libgcc/unwind-dw2-fde-dip.c:454
#5  0x7f3a6ba6fb93 in uw_frame_state_for
(context=context@entry=0x7f3a516fd220, fs=fs@entry=0x7f3a516fd070) at
../../../libgcc/unwind-dw2.c:1241
#6  0x7f3a6ba70db0 in uw_init_context_1
(context=context@entry=0x7f3a516fd220,
outer_cfa=outer_cfa@entry=0x7f3a516fd5d0, outer_ra=0x7f3a6c2464cc
<__cxxabiv1::__cxa_throw(void*, std::type_info*, void (*)(void*))+92>) at
../../../libgcc/unwind-dw2.c:1562
#7  0x7f3a6ba7125e in _Unwind_RaiseException (exc=exc@entry=0x7f3a4c5e7470)
at ../../../libgcc/unwind.inc:88
#8  0x7f3a6c2464cc in __cxxabiv1::__cxa_throw(void*, std::type_info*, void
(*)(void*)) (obj=obj@entry=0x7f3a4c5e7490, tinfo=0x7f3a6f10f320 ,
tinfo@entry=0x7f3a6ebd4a98 ,
dest=dest@entry=0x7f3a6e1849e0
)
at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:82
#9  0x7f3a6e39a5ce in error_1(octave::execution_exception &, std::ostream
&, const char *, const char *, const char *, typedef __va_list_tag
__va_list_tag *, bool) (e=..., os=..., name=name@entry=0x7f3a6e7a1625 "error",
id=id@entry=0x7f3a6e796b04 "", fmt=,
fmt@entry=0x7f3a6e79b3f7 "%s: unknown %s property %s",
args=args@entry=0x7f3a516fd710, with_cfn=false) at
libinterp/corefcn/error.cc:512
#10 0x7f3a6e39a73e in error_1(std::ostream &, const char *, const char *,
const char *, typedef __va_list_tag __va_list_tag *, bool) (os=...,
name=name@entry=0x7f3a6e7a1625 "error", id=id@entry=0x7f3a6e796b04 "",
fmt=0x7f3a6e79b3f7 "%s: unknown %s property %s",
args=args@entry=0x7f3a516fd710, with_cfn=with_cfn@entry=false) at
libinterp/corefcn/error.cc:522
#11 0x7f3a6e39a797 in verror(char const*, __va_list_tag*) (fmt=, args=args@entry=0x7f3a516fd710) at libinterp/corefcn/error.cc:528
#12 0x7f3a6e39a839 in error(char const*, ...) (fmt=fmt@entry=0x7f3a6e79b3f7
"%s: unknown %s property %s") at libinterp/corefcn/error.cc:536
#13 0x7f3a6e41f28d in validate_property_name(std::__cxx11::string const&,
std::__cxx11::string const&, std::set,
std::less >, std::allocator > > const&, caseless_str const&)
(who="get", what="axes", pnames=std::set with 142 elements = {...}, pname=...)
at libinterp/corefcn/graphics.cc:101


(gdb) up
#1  0x7f3a6ba72859 in init_object (ob=0x7f3a4d3d4910)
at ../../../libgcc/unwind-dw2-fde.c:749
749   count = classify_object_over_fdes (ob, ob->u.single);
(gdb) print *ob
$5 = {pc_begin = 0x, tbase = 0x0, dbase = 0x0, u = {single =
0x7f3a6f220018,
array = 0x7f3a6f220018, sort = 0x7f3a6f220018}, s = {b = {sorted = 0,
from_array = 0,
  mixed_encoding = 0, encoding = 

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||baker at usgs dot gov

--- Comment #4 from Jeffrey A. Law  ---
*** Bug 53833 has been marked as a duplicate of this bug. ***

[Bug target/53833] m68k-uclinux xgcc ICE when compiling libgcc (linux-atomic.c:203:1: in emit_library_call_value_1, at calls.c:4146)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Jeffrey A. Law  ---
Tracking via 68467.  What we really need here is a .i file we can feed back
into the compiler for debugging purposes.

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

[Bug c/78408] New: Aggressive optimization of zeroing results in incorrect behavior

[npmccallum at redhat dot com]

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

Bug ID: 78408
   Summary: Aggressive optimization of zeroing results in
incorrect behavior
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: npmccallum at redhat dot com
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.2.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC)

Compiling the file uses this command line:

gcc -DPACKAGE_NAME=\"clevis\" -DPACKAGE_TARNAME=\"clevis\"
-DPACKAGE_VERSION=\"1\" -DPACKAGE_STRING=\"clevis\ 1\" -DPACKAGE_BUGREPORT=\"\"
-DPACKAGE_URL=\"\" -DPACKAGE=\"clevis\" -DVERSION=\"1\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -I.-Wall -Wextra -Werror -Wstrict-aliasing
-Wchar-subscripts -Wformat-security -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wpointer-arith -Wshadow -Wsign-compare -Wstrict-prototypes
-Wtype-limits -Wno-missing-field-initializers -Wno-unused-parameter  -pthread
-I/usr/include/udisks2 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-DCLEVIS_CMD_DIR=/usr/libexec/clevis -g -O2 -MT clevis-luks-udisks2.o -MD -MP
-MF $depbase.Tpo -c -o clevis-luks-udisks2.o clevis-luks-udisks2.c

The relevant code is here[1].

GCC sees that "pkt_t key" might go out of scope and therefore optimizes out the
zeroing of the struct that occurs at the end of the for loop iteration.
However, key doesn't go out of scope during loop iteration. Thus, on subsequent
loops the struct is used presuming that it contains a zero value but it
doesn't. This means that (what I take to be) perfectly valid ISO C behaves in
strange ways.

In particular, the bug that arises is as follows. When load_jwe() fails[2], the
(incorrectly) presumed zeroed key struct is sent[3] to the client. The end
result is that an invalid key (the previous successful one) is sent when an
empty UDP packet should be sent.

GCC should detect that "pkt_t key" is not going out of scope and should zero it
as requested rather than invalidly optimizing out this statement. Clang does
not have this bug, so there is at least one example of a compiler doing the
right thing.

[1] -
https://github.com/latchset/clevis/blob/6834b02b390771a97775dcfa26f85243f3a0195d/udisks2/clevis-luks-udisks2.c#L446
[2] -
https://github.com/latchset/clevis/blob/6834b02b390771a97775dcfa26f85243f3a0195d/udisks2/clevis-luks-udisks2.c#L455
[3] -
https://github.com/latchset/clevis/blob/6834b02b390771a97775dcfa26f85243f3a0195d/udisks2/clevis-luks-udisks2.c#L469

[Bug target/77600] M68K: gcc generates rubbish with -mshort

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |INVALID

--- Comment #2 from Jeffrey A. Law  ---
This is a similar issue as I outlined in the other m68k -mshort BZ.  This time
we need to look at how INTPTR_TYPE, which is defined in terms of
LONG_TYPE_SIZE.   When LONG_TYPE_SIZE == 32, INTPTR_TYPE will be an "int"
-mshort changes the size of an int from 32 to 16 bits.

Thus conversions to/from sizetype are going to do things you don't expect
unless you know sizetype is 16 bits.

Again, if you configure for a bare metal target such as m68k-elf or avoid using
-mshort on your linux target, you'll get the desired and expected result.

[Bug target/77599] M68K: __builtin_bswap32() isn't compiled correctly with -mshort

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |INVALID

--- Comment #2 from Jeffrey A. Law  ---
The problem here is you're using -mshort  on *-linux-gnu which IMHO is invalid.


Linux defines int32_t as a "int".  And -mshort changes the width of an int to
16 bits, at which point anything prototyped using int32_t has just changed its
ABI in a meaningful way (similarly for uint32_t, but unsigned).  You can see
this in the .optimized dump file:

x (long unsigned int y)
{
  unsigned int _1;
  unsigned int _2;
  long unsigned int _4;

;;   basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred:   ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
  _1 = (unsigned int) y_3(D);
  _2 = __builtin_bswap32 (_1);
  _4 = (long unsigned int) _2;
  return _4;
}

Note the type of the _1 and _2.  They are both unsigned ints, so 16 bits. 


If you try this test on a bare metal target such as m68k-elf or without the
-mshort, you'll get the expected and desired result.

[Bug fortran/78395] [OOP] ICE for operations with polymorphic variables

[cmacmackin at gmail dot com]

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

--- Comment #6 from Chris  ---
> Which one do you mean exactly? Shouldn't they all use the user-defined 
> assignment function?

Yes, that's right--they all should. Sorry, I didn't have the code up in front
of me when I wrote that so I was a bit imprecise in what I was saying.

[Bug libfortran/78379] Processor-specific versions for matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Here are some measurements with the AVX-enabling patch.
They were done on an AVX machine, namely gcc75 from the compile farm.

This was done with the command line

gfortran -static-libgfortran -finline-matmul-limit=0 -Ofast -o compare_mavx
compare_2.f90

Uncontidionally setting -mavx in the Makefile for matmul, with stock trunk:

 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  5000  0.067  0.077  0.051  0.069
3  5000  0.193  0.218  0.157  0.194
4  5000  0.429  0.423  0.368  0.435
5  5000  0.609  0.659  0.556  0.630
7  5000  0.948  1.018  0.931  1.009
8  5000  1.608  1.251  1.589  1.715
9  5000  1.755  1.484  1.745  1.856
   15  5000  2.710  2.175  2.963  3.105
   16  5000  4.289  2.510  4.541  4.784
   17  5000  4.411  3.032  4.675  4.888
   31  5000  6.165  4.395  6.912  6.902
   32  5000  8.800  4.362  8.793  8.809
   33  5000  8.156  4.463  8.145  8.193
   63  5000  9.727  4.364  9.709  9.716
   64  5000 11.828  4.023 11.810 11.798
   65  5000 10.726  4.489 10.654 10.725
  127  3920 12.144  4.292 12.281 12.268
  128  3829 13.829  4.484 13.807 13.841
  129  3741 12.986  4.438 12.964 12.985
  255   483 14.446  4.571 14.462 14.442
  256   477 15.738  4.707 15.744 15.738
  257   472 13.981  4.565 13.995 13.990
  51160 14.954  4.674 14.977 14.933
  51259 16.120  4.840 16.137 16.062
  51359 14.488  4.392 14.497 14.490
 1023 7 15.011  3.573 15.021 14.995
 1024 7 15.938  3.489 15.947 15.938
 1025 7 14.670  3.568 14.683 14.627

With library-side switching
(https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01810.html):

 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  5000  0.067  0.080  0.053  0.067
3  5000  0.192  0.226  0.159  0.192
4  5000  0.427  0.436  0.364  0.431
5  5000  0.588  0.664  0.543  0.621
7  5000  0.938  0.914  0.926  1.011
8  5000  1.589  1.235  1.558  1.671
9  5000  1.704  1.486  1.694  1.810
   15  5000  2.638  2.175  2.854  3.031
   16  5000  4.234  2.532  4.533  4.745
   17  5000  4.374  3.044  4.677  4.839
   31  5000  6.207  4.401  6.891  6.918
   32  5000  8.824  4.364  8.614  8.603
   33  5000  7.954  4.349  7.945  7.944
   63  5000  8.802  4.369  9.728  9.764
   64  5000 11.845  4.025 11.783 11.849
   65  5000 10.753  4.595 10.719 10.753
  127  3920 12.023  4.314 12.285 12.004
  128  3829 13.427  4.369 13.722 13.742
  129  3741 12.877  4.323 12.668 12.985
  255   483 14.398  4.453 14.336 13.496
  256   477 15.708  4.680 15.711 15.465
  257   472 13.977  4.439 13.965 13.977
  51160 14.920  4.691 14.937 14.939
  51259 15.959  4.787 16.084 16.082
  51359 14.444  4.636 14.464 14.452
 1023 7 14.978  3.448 14.979 14.980
 1024 7 15.903  3.640 15.900 15.905
 1025 7 14.638  3.464 14.626 14.636

With stock trunk:

 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  5000  0.072  0.078  0.053  0.072
3  5000  0.199  0.224  

[Bug libfortran/78379] Processor-specific versions for matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
Created attachment 40074
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40074=edit
Test program for benchmarks

[Bug fortran/78395] [OOP] ICE for operations with polymorphic variables

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Chris from comment #4)
> I tried compiling (my original example) on a different box, this one with
> gfortran 6.2.0 obtained from the ubuntu-toolchain-r/test PPA. I got
> 
> [..]
> gcc version 6.2.0 20160901 (Ubuntu 6.2.0-3ubuntu11~16.04) 

My gfortran-6 version is what currently is in Ubuntu 16.10:

gcc version 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12)

and that does not give an ICE, but the error shown above.


> Would there be some issue with the build which is causing the ICE for me?

Not sure. Since our versions differ a bit, the most probable scenario is that
the different behavior was caused by some recent backport (unfortunately Ubuntu
does not give exact revision numbers). One should check the logfile:

https://gcc.gnu.org/viewcvs/gcc/branches/gcc-6-branch/gcc/fortran/ChangeLog?view=markup


> The error message which you reported for gfortran 6.2.0 also doesn't make
> sense to me, as I use defined-assignment to allocatable variables frequently
> in my code without problem.

True. Didn't notice that. I guess the error should only apply to intrinsic
assignment, not user-defined. So maybe that's a bug after all.


> Indeed, it is used a line or two earlier in the
> example I provided.

Which one do you mean exactly? Shouldn't they all use the user-defined
assignment function?

In any case the error is thrown on the last line, and I also get it on the
reduced example in comment 3:


$ gfortran-6 c3.f90 
c3.f90:62:2:

   v6 = 3 * v4%get_t2() ! This line is the one which causes ICE
  1
Error: Assignment to an allocatable polymorphic variable at (1) is not yet
supported

[Bug lto/78407] New: LTO breaks separate overriding of symbol aliases

[srk31 at srcf dot ucam.org]

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

Bug ID: 78407
   Summary: LTO breaks separate overriding of symbol aliases
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: srk31 at srcf dot ucam.org
  Target Milestone: ---

Created attachment 40073
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40073=edit
Test case tarball

I have a library which tests, in a constructor function, whether another
library is overriding one of its symbols. If so, it skips initialization (since
the other library is taking care of it). This is necessary because constructors
cannot meaningfully be overridden.

To do this test, I create a hidden alias of the overridable symbol. This will
always point to our copy, even if the global alias gets overridden.

int foo = 0;

extern int our_foo __attribute__((visibility("hidden"),alias("foo")));

static void (__attribute__((constructor)) init)(void)
{
if (_foo != )
{
/* skip init */
}
else
{
/* do init */
}
}

Building this library with LTO works fine on gcc 4.9.3 and earlier. On 5.x and
6.x the address comparison gets wrongly optimised away (tested on 5.2.1 and
6.2.0). In 4.9.x I get:

06c0 :
 6c0:   55  push   %rbp
 6c1:   48 89 e5mov%rsp,%rbp
 6c4:   48 8d 05 5e 09 20 00lea0x20095e(%rip),%rax 
 6cb:   48 8b 15 06 09 20 00mov0x200906(%rip),%rdx 
 6d2:   48 39 d0cmp%rdx,%rax
 6d5:   74 1a   je 6f1 
...

i.e. a cmp instruction, whereas with 5.2.1 there is none.

06b0 :
 6b0:   55  push   %rbp
 6b1:   48 89 e5mov%rsp,%rbp
 6b4:   48 8d 35 f5 ff ff fflea-0xb(%rip),%rsi# 6b0 
 6bb:   48 8d 3d 17 00 00 00lea0x17(%rip),%rdi# 6d9 <_fini+0x9>
 6c2:   b8 00 00 00 00  mov$0x0,%eax
 6c7:   e8 c4 fe ff ff  callq  590 
 6cc:   5d  pop%rbp
 6cd:   c3  retq   

Unless I'm mistaken: for any two ELF symbol aliases, if at least one has global
visibility, LTO cannot assume they will remain aliased at run time.

Tarball attached. On doing "make run", "lib1" should only claim to initialize
itself once, but it happens twice on 5.x+.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[vogt at linux dot vnet.ibm.com]

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

--- Comment #14 from Dominik Vogt  ---
With the fix I couldn't reproduce the error message in four attempts, but
genattrtab still hangs.  Maybe this is bad luck, but maybe the error is gone. 
Running a regression test without bootstrapping on s390x, --with-arch=zEC12,
--languages=c, there is a long list of tests that fail:

 Running target unix/-m64
+FAIL: gcc.c-torture/execute/20030408-1.c   -O1  execution test
+FAIL: gcc.c-torture/execute/20040709-1.c   -O1  execution test
+FAIL: gcc.c-torture/execute/930921-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gcc.c-torture/execute/930921-1.c   -Os  execution test
+FAIL: gcc.c-torture/execute/builtin-bitops-1.c   -O2  execution test
+FAIL: gcc.c-torture/execute/builtin-bitops-1.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
+FAIL: gcc.c-torture/execute/builtin-bitops-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
+FAIL: gcc.c-torture/execute/pr53645-2.c   -O1  execution test
+FAIL: gcc.c-torture/execute/pr53645-2.c   -O2  execution test
+FAIL: gcc.c-torture/execute/pr53645-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
+FAIL: gcc.c-torture/execute/pr53645-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
+FAIL: gcc.c-torture/execute/pr53645-2.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gcc.c-torture/execute/pr53645-2.c   -O3 -g  execution test
+FAIL: gcc.c-torture/execute/pr53645-2.c   -Os  execution test
+FAIL: gcc.c-torture/execute/pr53688.c   -O1  execution test
+FAIL: gcc.c-torture/execute/pr53688.c   -O2  execution test
+FAIL: gcc.c-torture/execute/pr53688.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
+FAIL: gcc.c-torture/execute/pr53688.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
+FAIL: gcc.c-torture/execute/pr53688.c   -O3 -g  execution test
+FAIL: gcc.c-torture/execute/pr53688.c   -Os  execution test
+FAIL: gcc.c-torture/execute/pr63302.c   -O1  execution test
+FAIL: gcc.c-torture/execute/pr63302.c   -O2  execution test
+FAIL: gcc.c-torture/execute/pr63302.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
+FAIL: gcc.c-torture/execute/pr63302.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
+FAIL: gcc.c-torture/execute/pr63302.c   -O3 -g  execution test
+FAIL: gcc.c-torture/execute/pr63302.c   -Os  execution test
+FAIL: gcc.c-torture/execute/scal-to-vec1.c   -O1  execution test
+FAIL: gcc.c-torture/execute/scal-to-vec2.c   -O1  execution test
+FAIL: gcc.c-torture/execute/scal-to-vec2.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gcc.c-torture/execute/scal-to-vec2.c   -O3 -g  execution test
+FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -O1  execution test
+FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -O2  execution test
+FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
+FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
+FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -O3 -g  execution test
+FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -Os  execution test
+FAIL: gcc.dg/ftrapv-2.c execution test
+FAIL: gcc.dg/ftrapv-3.c execution test
+FAIL: gcc.dg/guality/const-volatile.c   -O1  execution test
+FAIL: gcc.dg/guality/const-volatile.c   -O2  execution test
+FAIL: gcc.dg/guality/const-volatile.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
+FAIL: gcc.dg/guality/const-volatile.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
+FAIL: gcc.dg/guality/const-volatile.c   -O3 -g  execution test
+FAIL: gcc.dg/guality/const-volatile.c   -Os  execution test
+FAIL: gcc.dg/sso/p3.c   -O1 -fno-inline  output pattern test, is My_R1: c2
7b f3 2a 5e 12 9a 95
+FAIL: gcc.dg/sso/p3.c   -O2  output pattern test, is My_R1: c2 7b f3 2a 5e
12 9a 95
+FAIL: gcc.dg/sso/p3.c   -O3 -finline-functions  output pattern test, is My_R1 
  : c2 7b f3 2a 5e 12 9a 95
+FAIL: gcc.dg/sso/p3.c   -Os  output pattern test, is My_R1: c2 7b f3 2a 5e
12 9a 95
+FAIL: gcc.dg/torture/pr43000.c   -O1  execution test
+FAIL: gcc.dg/torture/pr43000.c   -O2  execution test
+FAIL: gcc.dg/torture/pr43000.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
+FAIL: gcc.dg/torture/pr43000.c   -O3 -g  execution test
+FAIL: gcc.dg/torture/pr43000.c   -Os  execution test
+FAIL: gcc.target/s390/risbg-ll-1.c scan-assembler
f43:\\n\\trisbg\\t%r2,%r2,32,128+61,64-12
+FAIL: gcc.target/s390/risbg-ll-2.c scan-assembler
f9:\\n\\trisbg\\t%r3,%r2,48,63,64-48

[Bug middle-end/78406] Crafty v23.4 is 20% slower under GCC 6.2 than under Clang 3.9

[t.artem at mailcity dot com]

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

--- Comment #2 from Artem S. Tashkinov  ---
(In reply to Markus Trippelsdorf from comment #1)
> Artem, please don't open a new bug for every phoronix benchmark where gcc
> appears to be slower than clang.
> 
> First of all there are existing bug report for many of the issues.
> And secondly phoronix is famous for its bogus benchmark numbers, 
> so please take them with a big grain of salt.

I'm terribly sorry. Still there are no obvious duplicates for any of the
recently reported bugs.

I don't pay attention when one compiler is 10%, give or take, faster than
another. However this recent test shows some major differences so I was worried
that maybe GCC 6.2.0 is falling behind.

[Bug middle-end/78201] [7 Regression] ICE in tree_to_shwi, at tree.h:4037 (seen both on ARM32 an AArch64)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/78201] [7 Regression] ICE in tree_to_shwi, at tree.h:4037 (seen both on ARM32 an AArch64)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 17 17:09:13 2016
New Revision: 242555

URL: https://gcc.gnu.org/viewcvs?rev=242555=gcc=rev
Log:
PR middle-end/78201
* varasm.c (default_use_anchors_for_symbol_p): Fix a comment typo.
Don't test decl != NULL.  Don't look at DECL_SIZE, but DECL_SIZE_UNIT
instead, return false if it is NULL, or doesn't fit into uhwi, or
is larger or equal to targetm.max_anchor_offset.

* g++.dg/opt/pr78201.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr78201.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug c/78406] Crafty v23.4 is 20% slower under GCC 6.2 than under Clang 3.9

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org
  Component|middle-end  |c

--- Comment #1 from Markus Trippelsdorf  ---
Artem, please don't open a new bug for every phoronix benchmark where gcc
appears to be slower than clang.

First of all there are existing bug report for many of the issues.
And secondly phoronix is famous for its bogus benchmark numbers, 
so please take them with a big grain of salt.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[vogt at linux dot vnet.ibm.com]

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

--- Comment #13 from Dominik Vogt  ---
I'm doing this on s390x right now.  Just takes some more time.

[Bug c/78406] New: Crafty v23.4 is 20% slower under GCC 6.2 than under Clang 3.9

[t.artem at mailcity dot com]

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

Bug ID: 78406
   Summary: Crafty v23.4 is 20% slower under GCC 6.2 than under
Clang 3.9
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.artem at mailcity dot com
  Target Milestone: ---

http://www.phoronix.com/scan.php?page=article=gcc-clang-kblclear=4

GCC 6.2.0 - 95 seconds
Clang 3.9.0 - 78 seconds

GCC options: -lstdc++ -lm

CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)

[Bug c/78405] New: OpenSSL v1.0.1g RSA 4096 test is 20% slower under GCC 6.2 than under Clang 3.9

[t.artem at mailcity dot com]

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

Bug ID: 78405
   Summary: OpenSSL v1.0.1g RSA 4096 test is 20% slower under GCC
6.2 than under Clang 3.9
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.artem at mailcity dot com
  Target Milestone: ---

http://www.phoronix.com/scan.php?page=article=gcc-clang-kblclear=4

GCC 6.2.0 - 243
Clang 3.9.0 - 289

GCC options: -m64 -O3 -lssl -lcrypto -ldl

CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[matz at gcc dot gnu.org]

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

--- Comment #12 from Michael Matz  ---
(In reply to Andreas Schwab from comment #11)
> That didn't fix the ia64 bootstrap failure.

Would have been too easy I guess :-)  Okay, can you try to find a testcase
that regressed by not bootstrapping but running the testsuite?

[Bug fortran/78395] [OOP] ICE for operations with polymorphic variables

[cmacmackin at gmail dot com]

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

--- Comment #4 from Chris  ---
I tried compiling (my original example) on a different box, this one with
gfortran 6.2.0 obtained from the ubuntu-toolchain-r/test PPA. I got

Driving: gfortran-6 -v minimal.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran-6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
6.2.0-3ubuntu11~16.04' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.0 20160901 (Ubuntu 6.2.0-3ubuntu11~16.04) 
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/6/f951 minimal.f90 -quiet -dumpbase minimal.f90
-mtune=generic -march=x86-64 -auxbase minimal -version -fintrinsic-modules-path
/usr/lib/gcc/x86_64-linux-gnu/6/finclude -o /tmp/chris/ccDLOYCy.s
GNU Fortran (Ubuntu 6.2.0-3ubuntu11~16.04) version 6.2.0 20160901
(x86_64-linux-gnu)
compiled by GNU C version 6.2.0 20160901, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (Ubuntu 6.2.0-3ubuntu11~16.04) version 6.2.0 20160901
(x86_64-linux-gnu)
compiled by GNU C version 6.2.0 20160901, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:241
0x5dede4 gfc_add_component_ref(gfc_expr*, char const*)
../../src/gcc/fortran/class.c:241
0x6564f1 resolve_typebound_function
../../src/gcc/fortran/resolve.c:6014
0x6564f1 gfc_resolve_expr(gfc_expr*)
../../src/gcc/fortran/resolve.c:6357
0x60730a gfc_extend_expr(gfc_expr*)
../../src/gcc/fortran/interface.c:3943
0x656064 resolve_operator
../../src/gcc/fortran/resolve.c:3850
0x656064 gfc_resolve_expr(gfc_expr*)
../../src/gcc/fortran/resolve.c:6339
0x65cab3 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../src/gcc/fortran/resolve.c:10459
0x65f282 resolve_codes
../../src/gcc/fortran/resolve.c:15656
0x65f37e gfc_resolve(gfc_namespace*)
../../src/gcc/fortran/resolve.c:15691
0x64a62a resolve_all_program_units
../../src/gcc/fortran/parse.c:5854
0x64a62a gfc_parse_file()
../../src/gcc/fortran/parse.c:6106
0x68c1c2 gfc_be_parse_file
../../src/gcc/fortran/f95-lang.c:201
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Would there be some issue with the build which is causing the ICE for me? The
error message which you reported for gfortran 6.2.0 also doesn't make sense to
me, as I use defined-assignment to allocatable variables frequently in my code
without problem. Indeed, it is used a line or two earlier in the example I
provided.

[Bug c++/78404] New: SciMark v2.0 Sparse Matrix Multiply test is 20% slower under GCC 6.2 than under Clang 3.9

[t.artem at mailcity dot com]

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

Bug ID: 78404
   Summary: SciMark v2.0 Sparse Matrix Multiply test is 20% slower
under GCC 6.2 than under Clang 3.9
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.artem at mailcity dot com
  Target Milestone: ---

As per
http://www.phoronix.com/scan.php?page=article=gcc-clang-kblclear=2

GCC 6.2.0 - 1835
Clang 3.9.0 - 2204

g++ options: -O3 -march=native

CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)

[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU

[avieira at gcc dot gnu.org]

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

--- Comment #6 from avieira at gcc dot gnu.org ---
I had a look at this and after some digging I found the bug is not due to LTO,
but rather with "local" functions. If you make bar static you will end up with
the same faulty behavior.

After some more digging I found myself going through the 'untyped_call' code in
arm.md. Here I found both 'untyped_call' and 'untyped_return' had not been
adjusted to be able to cope with HardFP ABI's.  I wrote a patch to mend this,
needs a bit more work, but I think it's correct and I might put it on
gcc-patches at a later time.

However, when I started thinking of how I was going to "fix" this wrong-code
generation, I realized that due to the way untyped_call's and untyped_return's
are constructed and the nature of '__builtin_return' and '__builtin_apply', you
do not know which registers are actually used to return the values, you only
know it might be 'r0-r4' and 'd0-d7'. So even though I know the call-site would
expect a return of type 'double' in 'r0-r1', because this is local function
(aka 'ARM_PCS_AAPCS_LOCAL') and the target does not support double precision,
there is no way for me to know in which of the registers the function is
actually returning, so I dont know what registers to move to 'r0-r1'.

So  I don't think we can get this builtin to work for single precision
VFPs, without compromising on the way we use local function returns.

[Bug c++/78403] New: SciMark v2.0 Jacobi Successive Over-Relaxation test is 30% slower under GCC 6.2 than under Clang 3.9

[t.artem at mailcity dot com]

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

Bug ID: 78403
   Summary: SciMark v2.0 Jacobi Successive Over-Relaxation test is
30% slower under GCC 6.2 than under Clang 3.9
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.artem at mailcity dot com
  Target Milestone: ---

As per
http://www.phoronix.com/scan.php?page=article=gcc-clang-kblclear=2

GCC 6.2.0 - 875
Clang 3.9.0 - 1162

g++ options: -O3 -march=native

CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)

[Bug c++/78402] New: SciMark v2.0 Dense LU Matrix Factorization test runs more than 2 times slower under GCC 6.2 than under Clang 3.9

[t.artem at mailcity dot com]

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

Bug ID: 78402
   Summary: SciMark v2.0  Dense LU Matrix Factorization test runs
more than 2 times slower under GCC 6.2 than under
Clang 3.9
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.artem at mailcity dot com
  Target Milestone: ---

As per
http://www.phoronix.com/scan.php?page=article=gcc-clang-kblclear=2

GCC 6.2.0 - 1834
Clang 3.9.0 - 4165

g++ options: -O3 -march=native

CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)

[Bug c++/78401] New: SciMark v2.0 Composite test runs 1,5 times slower under GCC 6.2 than under Clang 3.9

[t.artem at mailcity dot com]

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

Bug ID: 78401
   Summary: SciMark v2.0 Composite test runs 1,5 times slower
under GCC 6.2 than under Clang 3.9
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.artem at mailcity dot com
  Target Milestone: ---

As per
http://www.phoronix.com/scan.php?page=article=gcc-clang-kblclear=2

GCC 6.2.0 - 1057
Clang 3.9.0 - 1603

g++ options: -O3 -march=native

CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

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

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

--- Comment #11 from Andreas Schwab  ---
That didn't fix the ia64 bootstrap failure.

[Bug rtl-optimization/78400] New: [7 Regression] ICE: in df_refs_verify, at df-scan.c:4045 when building powerpc crosscompiler

[zsojka at seznam dot cz]

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

Bug ID: 78400
   Summary: [7 Regression] ICE: in df_refs_verify, at
df-scan.c:4045 when building powerpc crosscompiler
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: powerpc-unknown-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 40072
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40072=edit
reduced testcase

Compiler output:
$ $
/repo/build-trunk-242552-checking-yes-rtl-df-extra-nographite-powerpc/./gcc/cc1
-quiet -O2 testcase.c
testcase.c: In function 'foo':
testcase.c:7:1: internal compiler error: in df_refs_verify, at df-scan.c:4045
 }
 ^
0x7924a2 df_refs_verify
/repo/gcc-trunk/gcc/df-scan.c:4045
0x797f30 df_insn_refs_verify
/repo/gcc-trunk/gcc/df-scan.c:4125
0x79a272 df_bb_verify
/repo/gcc-trunk/gcc/df-scan.c:4154
0x79a597 df_scan_verify()
/repo/gcc-trunk/gcc/df-scan.c:4286
0x782e78 df_verify()
/repo/gcc-trunk/gcc/df-core.c:1831
0x782efa df_analyze_1
/repo/gcc-trunk/gcc/df-core.c:1217
0xb8d304 try_shrink_wrapping_separate(basic_block_def*)
/repo/gcc-trunk/gcc/shrink-wrap.c:1694
0x8b0d7f thread_prologue_and_epilogue_insns()
/repo/gcc-trunk/gcc/function.c:5960
0x8b1572 rest_of_handle_thread_prologue_and_epilogue
/repo/gcc-trunk/gcc/function.c:6419
0x8b1572 execute
/repo/gcc-trunk/gcc/function.c:6461
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

$
/repo/build-trunk-242552-checking-yes-rtl-df-extra-nographite-powerpc/./gcc/xgcc
-v
Using built-in specs.
COLLECT_GCC=/repo/build-trunk-242552-checking-yes-rtl-df-extra-nographite-powerpc/./gcc/xgcc
Target: powerpc-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl
--with-sysroot=/usr/powerpc-unknown-linux-gnu
--target=powerpc-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=powerpc-unknown-linux-gnu
--with-ld=/usr/bin/powerpc-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-242552-checking-yes-rtl-df-extra-nographite-powerpc
Thread model: posix
gcc version 7.0.0 20161117 (experimental) (GCC) 


The compiler was configured with --enable-checking=yes,rtl,df,extra ; maybe df
checking is needed to reproduce.

[Bug tree-optimization/78394] False positives of maybe-uninitialized with -Og

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
I can confirm it only happens with the -Og optimization level; I also tested
-Ofast and -Os, and neither of those triggered it either.

gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O0 maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Og maybe_uninit_00.cpp
maybe_uninit_00.cpp: In function ‘float foo()’:
maybe_uninit_00.cpp:19:17: warning: ‘vy’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
 return vx + vy;
 ^~
maybe_uninit_00.cpp:19:17: warning: ‘vx’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O1 maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O2 maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O3 maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Ofast maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Os maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O0 maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O0 -g maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Og maybe_uninit_01.cpp
maybe_uninit_01.cpp: In function ‘float foo()’:
maybe_uninit_01.cpp:19:17: warning: ‘vy’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
 return vx + vy;
 ^~
maybe_uninit_01.cpp:19:17: warning: ‘vx’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Ofast maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Ofast -g maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Os maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Os -g maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/7.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release -C
--with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --with-isl --enable-objc-gc --disable-host-shared
--enable-maintainer-mode --disable-default-pie --with-ld64 --without-pic
CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ AUTOCONF=/usr/local/bin/autoconf
AUTOHEADER=/usr/local/bin/autoheader AUTORECONF=/usr/local/bin/autoreconf
AUTOM4TE=/usr/local/bin/autom4te AUTOSCAN=/usr/local/bin/autoscan
AUTOUPDATE=/usr/local/bin/autoupdate IFNAMES=/usr/local/bin/ifnames
Thread model: posix
gcc version 7.0.0 20161027 (experimental) (GCC)

[Bug c++/78399] g++ generates sub-optimal assembler code when structs aren't explicitly aligned.

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
Related to PR 50384.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[matz at gcc dot gnu.org]

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

--- Comment #10 from Michael Matz  ---
(In reply to Dominik Vogt from comment #9)
> On Thu, Nov 17, 2016 at 03:03:03PM +, matz at gcc dot gnu.org wrote:
> 
> I'm just bootstrapping s390x with the fix; would you like me to
> run a regression test against the fixed patch?

Cool, thanks.  If bootstrap is still not working then it would help to
have a testcase that breaks on s390x, not a whole miscompiled compiler :)
So, if still broken please run a reg-test without bootstrap with and without
that revision and see if there are any testcases breaking.

[Bug rtl-optimization/78355] LRA generates unaligned accesses when SLOW_UNALIGNED_ACCESS is 1

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #9 from Eric Botcazou  ---
Thanks for reporting the problem and fixing it at the same time!

[Bug rtl-optimization/78355] LRA generates unaligned accesses when SLOW_UNALIGNED_ACCESS is 1

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Nov 17 16:16:38 2016
New Revision: 242554

URL: https://gcc.gnu.org/viewcvs?rev=242554=gcc=rev
Log:
PR rtl-optimization/78355
* doc/tm.texi.in (SLOW_UNALIGNED_ACCESS): Document that the macro only
needs to deal with unaligned accesses.
* doc/tm.texi: Regenerate.
* lra-constraints.c (simplify_operand_subreg): Only invoke
SLOW_UNALIGNED_ACCESS on innermode if the MEM is not aligned enough.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/lra-constraints.c

[Bug c++/78399] g++ generates sub-optimal assembler code when structs aren't explicitly aligned.

[lucanus81 at gmail dot com]

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

--- Comment #1 from Luca Stoppa  ---
Created attachment 40071
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40071=edit
Optimal code

[Bug tree-optimization/46639] [5/6 Regression] Missing optimization due to function splitting and redundant conditionals

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] Missing  |[5/6 Regression] Missing
   |optimization due to |optimization due to
   |function splitting and  |function splitting and
   |redundant conditionals  |redundant conditionals

--- Comment #19 from Jeffrey A. Law  ---
Early FRE picks this up in gcc-7.

[Bug c++/78399] New: g++ generates sub-optimal assembler code when structs aren't explicitly aligned.

[lucanus81 at gmail dot com]

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

Bug ID: 78399
   Summary: g++ generates sub-optimal assembler code when structs
aren't explicitly aligned.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucanus81 at gmail dot com
  Target Milestone: ---

Created attachment 40070
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40070=edit
suboptimal code

Consider the following example:

struct pod { char x[7]; };
pod copy_pod(pod d) { return d; }

gcc (at any optimization level) will general sub-optimal assembler code (see
attachment).
The interesting thing is that if we change "pod" to contain a number of bytes
that fit into a cpu register (2, 4, 8, 16, 32, 64) then the generated assembler
is optimal (see attachment)

struct pod { char x[8]; };
pod copy_pod(pod d) { return d; }

One workaround I found is to explicitly use alignas:
struct alignas(8) pod { char x[7]; }; 

I'm wondering whether gcc should generate optimal code even without alignas(8).

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[vogt at linux dot vnet.ibm.com]

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

--- Comment #9 from Dominik Vogt  ---
On Thu, Nov 17, 2016 at 03:03:03PM +, matz at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
> 
> --- Comment #8 from Michael Matz  ---
> The aarch64 fail is fixed by the below patch.  It will take a while for me
> to try this on s390, so if somebody beats me to test this I won't complain.

I'm just bootstrapping s390x with the fix; would you like me to
run a regression test against the fixed patch?

Ciao

Dominik ^_^  ^_^

[Bug preprocessor/78324] Valgrind issues seen with gcc.dg/tree-ssa/builtin-sprintf-2.c

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Author: dmalcolm
Date: Thu Nov 17 15:55:26 2016
New Revision: 242552

URL: https://gcc.gnu.org/viewcvs?rev=242552=gcc=rev
Log:
Fix locations within raw strings

Whilst investigating PR preprocessor/78324 I noticed that the
substring location code currently doesn't handle raw strings
correctly, by not skipping the 'R', opening quote, delimiter
and opening parenthesis.

For example, an attempt to underline chars 4-7 with caret at 6 of
this raw string yields this erroneous output:
   __emit_string_literal_range (R"foo(0123456789)foo",
~~^~

With the patch, the correct range/caret is printed:

   __emit_string_literal_range (R"foo(0123456789)foo",
  ~~^~

gcc/ChangeLog:
* input.c (selftest::test_lexer_string_locations_long_line): New
function.
(selftest::test_lexer_string_locations_raw_string_multiline): New
function.
(selftest::input_c_tests): Call the new functions, via
for_each_line_table_case.

gcc/testsuite/ChangeLog:
* gcc.dg/plugin/diagnostic-test-string-literals-1.c
(test_raw_string_one_liner): New function.
(test_raw_string_multiline): New function.

libcpp/ChangeLog:
* charset.c (cpp_interpret_string_1): Skip locations from
loc_reader when advancing 'p' when handling raw strings.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/input.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-1.c
trunk/libcpp/ChangeLog
trunk/libcpp/charset.c

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Vincent Lefèvre  ---
(In reply to Vincent Lefèvre from comment #0)
> By definition, for radix b = 2, LDBL_MAX is the value (1 - 2^(-p)) * 2^emax
> (see §5.2.4.2.2p12), which is the largest value representable in the
> floating-point model.

There has been a defect report and this is no longer the case. See:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2092.htm

"DR 467 decided that FLT_MAX, DBL_MAX, LDBL_MAX are the maximum representable
finite numbers for their respective types."

So, this solves this issue: LDBL_MAX is correct according to this DR. As a
consequence, I'm resolving the PR as invalid.

[Bug fortran/78395] [OOP] ICE for operations with polymorphic variables

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
Somewhat reduced test case (without all the abstract stuff):


module types_mod
  implicit none

  type, public :: t1
integer :: a
  contains
procedure :: get_t2
  end type

  type, public :: t2
integer :: b
  contains
procedure, pass(rhs) :: mul2
procedure :: assign
generic :: operator(*) => mul2
generic :: assignment(=) => assign
  end type

contains

  function get_t2(this)
class(t1), intent(in) :: this
class(t2), allocatable :: get_t2
type(t2), allocatable :: local
allocate(local)
local%b = this%a
call move_alloc(local, get_t2)
  end function

  function mul2(lhs, rhs)
class(t2), intent(in) :: rhs
integer, intent(in) :: lhs
class(t2), allocatable :: mul2
type(t2), allocatable :: local
allocate(local)
local%b = rhs%b*lhs
call move_alloc(local, mul2)
  end function

  subroutine assign(this, rhs)
class(t2), intent(out) :: this
class(t2), intent(in)  :: rhs
select type(rhs)
type is(t2)
  this%b = rhs%b
class default
  error stop
end select
  end subroutine

end module


program minimal
  use types_mod
  implicit none

  class(t1), allocatable :: v4
  class(t2), allocatable :: v6

  allocate(v4, source=t1(4)) ! Also fails if I use `allocate(t1 :: v4)`
  v6 = 3 * v4%get_t2() ! This line is the one which causes ICE

end

[Bug target/78386] [PPC] Optimization -O2 and higher cause math inconsistency

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #11 from Bill Schmidt  ---
Looks like this is WAD.  From the documentation:

  -ffp-contract=style

  ‘-ffp-contract=off’ disables floating-point expression contraction. ‘-ffp- 
contract=fast’ enables floating-point expression contraction such as forming of
fused multiply-add operations if the target has native support for them.
‘-ffp-contract=on’ enables floating-point expression contraction if allowed by
the language standard. This is currently not implemented and treated equal to
‘-ffp-contract=off’.

  The default is ‘-ffp-contract=fast’.

Also, from internal commentary this default is associated with the default
standard, which is -std=gnu11.  "In strict C standards comformance mode,
consider unpredictable excess precision to mean lack of IEEE 754 support.  The
same applies to unpredictable contraction.  For C++, and outside strict
conformance mode, do not consider these options to mean lack of IEEE 754
support."  This is why using -std=c11, for example, solves the "problem."

Thus, looks like your best option is to use -ffp-contract=off to get the
desired results.

Thanks,
Bill

[Bug target/78386] [PPC] Optimization -O2 and higher cause math inconsistency

[dje at gcc dot gnu.org]

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

--- Comment #10 from David Edelsohn  ---
-std=gnuXX affects IEEE 754 conformance, but that is not mentioned in the
documentation, only in source code comments (c-family/c-cppbuiltin.c)

[Bug fortran/78395] [OOP] ICE for operations with polymorphic variables

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
> gfortran 6.2.0 says:
> 
>v6 = 3 * v4%get_t2() ! This line is the one which causes ICE
>   1
> Error: Assignment to an allocatable polymorphic variable at (1) is not yet
> supported

It seems this error message was removed on trunk by Andre's r241439.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

[matz at gcc dot gnu.org]

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

--- Comment #8 from Michael Matz  ---
The aarch64 fail is fixed by the below patch.  It will take a while for me
to try this on s390, so if somebody beats me to test this I won't complain.

diff --git a/gcc/combine.c b/gcc/combine.c
index 0210685..05b6554 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -7380,6 +7380,7 @@ make_extraction (machine_mode mode, rtx inner,
HOST_WIDE_INT pos,
   || !REG_P (inner)
   || TRULY_NOOP_TRUNCATION_MODES_P (tmode, inner_mode)
   || reg_truncated_to_mode (tmode, inner))
+  && (REG_P (inner) || pos == 0)
   && (! in_dest
   || (REG_P (inner)
   && have_insn_for (STRICT_LOW_PART, tmode