[Bug c++/83921] [7/8 Regression] GCC rejects constexpr initialization of empty aggregate.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-18
 CC||jakub at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
   Target Milestone|--- |7.3
Summary|GCC rejects constexpr   |[7/8 Regression] GCC
   |initialization of empty |rejects constexpr
   |aggregate.  |initialization of empty
   ||aggregate.
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started to be rejected with r239268.
If it is a bug, it is therefore a regression.
clang++ doesn't seem to reject it, and even before the above revisions we'd
reject vars without initializers in constexpr functions if they weren't empty.

[Bug tree-optimization/83922] [8 Regression] ICE: Segmentation fault (in contains_struct_check)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-18
 CC||jakub at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r256625.

[Bug c/61240] [6/7/8 Regression] Incorrect warning "integer overflow in expression" on pointer-pointer subtraction

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 18 08:29:14 2018
New Revision: 256838

URL: https://gcc.gnu.org/viewcvs?rev=256838&root=gcc&view=rev
Log:
PR c/61240
* match.pd ((P + A) - P, P - (P + A), (P + A) - (P + B)): For
pointer_diff optimizations use view_convert instead of convert.

* gcc.dg/pr61240.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr61240.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug ipa/83051] [8 Regression] ICE on valid code at -O3: in edge_badness, at ipa-inline.c:1024

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #11 from Jan Hubicka  ---
Fixed.

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Sure, for working on GIMPLE the code needs to be adjusted.  On the other side,
the advantage is that it will then be able to handle even cases that it
couldn't before.
Like right now it can handle:
struct S { int a:5; int b:3; int c:2; };
void bar (void);

void
foo (struct S s)
{
  if (s.a == 7 && s.b == 6 && s.c == 1)
bar ();
}

but it could also handle

void
baz (struct S s)
{
  int a = s.a;
  int b = s.b;
  int c = s.c;
  if (a == 7 && b == 6 && c == 1)
bar ();
}

As to where exactly to implement it, as part of which other pass or as a new
pass I'd like to defer to richi.

[Bug c++/83921] [7/8 Regression] GCC rejects constexpr initialization of empty aggregate.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P2

[Bug c++/83919] [8 regression] spurious -Wignored-qualifiers warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Priority|P3  |P1
   Target Milestone|--- |8.0

[Bug c/61240] [6/7 Regression] Incorrect warning "integer overflow in expression" on pointer-pointer subtraction

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression]  |[6/7 Regression] Incorrect
   |Incorrect warning "integer  |warning "integer overflow
   |overflow in expression" on  |in expression" on
   |pointer-pointer subtraction |pointer-pointer subtraction

--- Comment #20 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/83916] [7/8 Regression] Internal compiler error on valid template code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P2

[Bug debug/83917] [8 Regression] with -mcall-ms2sysv-xlogues, stepping into x86 tail-call restore stub gives bad backtrace

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-debug
   Target Milestone|--- |8.0

--- Comment #1 from Richard Biener  ---
Testcase would be nice.

[Bug c++/83918] [8 Regression][c++17] ICE on constexpr eval of datatype involving function and variadic template

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |8.0
Summary|[c++17, regression from |[8 Regression][c++17] ICE
   |7.2] ICE on constexpr eval  |on constexpr eval of
   |of datatype involving   |datatype involving function
   |function and variadic   |and variadic template
   |template|

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
Note, it isn't just optimize_bit_field_compare, but also fold_truth_andor_1
that creates this stuff.  Doing this at gimple might have best framework in the
reassoc pass, because you need to look through conditions in multiple basic
blocks with no significant code in between, but also conditions bitwise ored or
anded within a single bb, i.e. the result of how multiple &&s or ||s are
lowered.
The reassoc pass is the only one with this kind of framework, in
optimize_range_tests.  Probably it would need to be done only in the second
reassoc pass, which, while it is before vrp2, it is only shortly before that
and as an advantage it there would be some time gimple passes to clean stuff up
if needed.

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
Testcase where in f1/f3/f5 this optimization is done early (already in
*.original dump), but in f2/f4/f6 is not.

struct S { unsigned a:5; unsigned b:3; unsigned c:2; };
void bar (void);

void
f1 (struct S s)
{
  if (s.a == 7 && s.b == 6 && s.c == 1)
bar ();
}

void
f2 (struct S s)
{
  unsigned a = s.a;
  unsigned b = s.b;
  unsigned c = s.c;
  if (a == 7 && b == 6 && c == 1)
bar ();
}

void
f3 (struct S s, struct S t)
{
  if (s.a == t.a && s.b == t.b && s.c == t.c)
bar ();
}

void
f4 (struct S s, struct S t)
{
  unsigned a = s.a;
  unsigned b = s.b;
  unsigned c = s.c;
  unsigned d = t.a;
  unsigned e = t.b;
  unsigned f = t.c;
  if (a == d && b == e && c == f)
bar ();
}

[Bug c++/83923] New: No destructor called for constructor argument

[mszyszkowski93 at gmail dot com]

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

Bug ID: 83923
   Summary: No destructor called for constructor argument
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mszyszkowski93 at gmail dot com
  Target Milestone: ---

Created attachment 43167
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43167&action=edit
Source files

gcc version 7.2.0 (GCC)
system type: x86_64-pc-linux-gnu 
command line to compile and run:
g++ -Wall -Wextra main.cpp && ./a.out 
and
g++ -Wall -Wextra main2.cpp && ./a.out  
for second version of program.

Binary from main.cpp, in which class is created by following way:
B* b = new B();
creates following output:

Constructor
0

Binary from main2.cpp, in which class is created by following way:
B* b = new B;
creates following output:

Constructor
0
Destructor

So destructor for B's constructor argument (A class) is not called when giving
'()'  when creating B.
Clang in version 5.0.0 produces:

Constructor
0
Destructor

in both cases. Source files included

[Bug c++/83919] [8 regression] spurious -Wignored-qualifiers warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-18
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r248432.

[Bug target/65578] FAIL: gcc.target/arm/builtin-bswap-1.c (test for excess errors)

[ktkachov at gcc dot gnu.org]

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Jan 18 09:30:58 2018
New Revision: 256840

URL: https://gcc.gnu.org/viewcvs?rev=256840&root=gcc&view=rev
Log:
[arm] PR target/65578: Fix builtin-bswap16-1.c and builtin-bswap-1.c

The builtin-bswap-1.c and builtin-bswap16-1.c are pretty annoying at the
moment.
They force an explicit armv6 option that is a thumb1 target, so if you're
testing a toolchain
configured with something like --with-cpu=cortex-a15 --with-float=hard
--with-mode=thumb
you'll get those pesky errors about Thumb1 hard-float not being implemented,
even though
the tests don't relate to floating-point functionality at all. I *think* this
is also due
to the wrong order of dg-options and dg-require-effective-target directives
that might
end up not doing a proper effective target check.

The solution in this patch is to commonise the code and create a couple of
tests for each.
One tests an armv6t2 target. This allows us to test an ARM or a Thumb2 target.
The second one sets an armv6-m target, which is a Thumb1 target.
The dg-add-options machinery for arm_arch_v6m knows how to add the right
-mfloat-abi=soft option.

With this patch we end up testing all of ARM, Thumb1, Thumb2 codegen whereas
before we only
ever tried testing Thumb1, if the multilib options happened to line up just
right, and would
give an ugly error otherwise.  Now, if the multilib options don't allow the
test it should just
appear as UNSUPPORTED.

PR target/65578
* gcc.target/arm/builtin-bswap.x: New file.
* gcc.target/arm/builtin-bswap-1.c: Include the above.  Add checks
and options for armv6t2.
* gcc.target/arm/builtin-bswap-2.c: Include the above.  Add checks
and options for Thumb1.
* gcc.target/arm/builtin-bswap16.x: New file.
* gcc.target/arm/builtin-bswap16-1.c: Include the above.  Add checks
and options for armv6t2.
* gcc.target/arm/builtin-bswap16-2.c: Include the above.  Add checks
and options for Thumb1.

Added:
trunk/gcc/testsuite/gcc.target/arm/builtin-bswap-2.c
trunk/gcc/testsuite/gcc.target/arm/builtin-bswap.x
trunk/gcc/testsuite/gcc.target/arm/builtin-bswap16-2.c
trunk/gcc/testsuite/gcc.target/arm/builtin-bswap16.x
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/builtin-bswap-1.c
trunk/gcc/testsuite/gcc.target/arm/builtin-bswap16-1.c

[Bug tree-optimization/83922] [8 Regression] ICE: Segmentation fault (in contains_struct_check)

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Mine

[Bug c++/83918] [8 Regression][c++17] ICE on constexpr eval of datatype involving function and variadic template

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-18
 CC||dmalcolm at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r256448.

Small formatting cleanup:
constexpr unsigned
foo (unsigned x, unsigned y)
{
  return x > b ? x : y;
}

template  struct A;
template  struct B;
template 
struct A , B >
{
  enum : unsigned
  {
u = foo (sizeof (S), sizeof (U)),
v = A , B >::w,
w = foo (u, v)
  };
};

template <>
struct A , B <>>
{
  enum : unsigned { w = 0 };
};

constexpr static const auto v { A ,
   B <9,8,7,6,5,4,3,2,1>>::w };
static_assert (v == sizeof (int));

[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used

[amker at gcc dot gnu.org]

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

--- Comment #10 from amker at gcc dot gnu.org ---
For the record, there is another possible fix.  Quoted loop nest from
gcc/testsuite/gfortran.dg/pr81303.f:

 do j=1,ny
jm1=mod(j+ny-2,ny)+1
jp1=mod(j,ny)+1
do i=1,nx
   im1=mod(i+nx-2,nx)+1
   ip1=mod(i,nx)+1
   do l=1,nb
  y(l,i,j,k)=0.0d0
  do m=1,nb
 y(l,i,j,k)=y(l,i,j,k)+
 ;; 
  enddo
   enddo
enddo
 enddo

Originally GCC can parallelize loop nest at i loop, but now GCC only
parallelize it at l loop because stmt "y(l,i,j,k)=0.0d0" is distributed into
memset into i loop.  As a result the distributed memset call can't be analyzed
by data reference analyzer.
An idea is to distribute the stmt to outer loop j, so at least we can
parallelize at loop level i as before.

Unfortunately this is not easy.  To distribute it into memset at loop level j,
we have to prove that memory range set to ZERO at each loop level doesn't leave
any bubble in it.
Given the array bound and loop niters are not constant, we need to prove
non-trivially equality for difference expressions.  This needs to be done in
function tree-loop-distribution.c:compute_access_range.  Specifically in this
function we have:

:
  _1 = *nb_113(D);
  ubound.86_114 = (integer(kind=8)) _1;
  stride.88_115 = MAX_EXPR ;

...

:  // thus in loop nest we have _1 > 0
  if (_1 <= 0)
goto ; [15.00%]
  else
goto ; [85.00%]

...

And in the end, we need to prove:

((sizetype) ((unsigned int) _1 + 4294967295) + 1) * 8
 == (sizetype) stride.88_115 * 8

We first need to prove:
((sizetype) ((unsigned int) _1 + 4294967295) + 1)
  == (sizetype) _1
using pre-condition "_1 > 0"

Then need to prove: MAX_EXPR  == ubound.86_114 also because
of "_1 > 0".

I doubt this can be done (without heavy messy code) in GCC now.  Or there might
be another way out of this?

Thanks,

[Bug c++/83918] [8 Regression][c++17] ICE on constexpr eval of datatype involving function and variadic template

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 43168
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43168&action=edit
gcc8-pr83918.patch

Untested fix.  The problem is that potential_constant_expression_1 assumes that
a VCE has always a non-NULL type, which used to be true, a type dependent
reinterpret_cast would be REINTERPRET_CAST_EXPR, but is no longer the case when
a VCE can be a location wrapper of a type dependent decl.

Fixed by ignoring location wrappers, they can't have different type of the
operand by definition, another possible fix would be check for non-NULL
TREE_TYPE first.

Note, not sure if the
  return (RECUR (from, TREE_CODE (t) != VIEW_CONVERT_EXPR));
line is right, shouldn't that be TREE_CODE (t) == VIEW_CONVERT_EXPR ? want_rval
: rval?  I mean, VCE can be used not just as lvalue, but also rvalue...

[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Thu, 18 Jan 2018, amker at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82604
> 
> --- Comment #10 from amker at gcc dot gnu.org ---
> For the record, there is another possible fix.  Quoted loop nest from
> gcc/testsuite/gfortran.dg/pr81303.f:
> 
>  do j=1,ny
> jm1=mod(j+ny-2,ny)+1
> jp1=mod(j,ny)+1
> do i=1,nx
>im1=mod(i+nx-2,nx)+1
>ip1=mod(i,nx)+1
>do l=1,nb
>   y(l,i,j,k)=0.0d0
>   do m=1,nb
>  y(l,i,j,k)=y(l,i,j,k)+
>  ;; 
>   enddo
>enddo
> enddo
>  enddo
> 
> Originally GCC can parallelize loop nest at i loop, but now GCC only
> parallelize it at l loop because stmt "y(l,i,j,k)=0.0d0" is distributed into
> memset into i loop.  As a result the distributed memset call can't be analyzed
> by data reference analyzer.
> An idea is to distribute the stmt to outer loop j, so at least we can
> parallelize at loop level i as before.
> 
> Unfortunately this is not easy.  To distribute it into memset at loop level j,
> we have to prove that memory range set to ZERO at each loop level doesn't 
> leave
> any bubble in it.
> Given the array bound and loop niters are not constant, we need to prove
> non-trivially equality for difference expressions.  This needs to be done in
> function tree-loop-distribution.c:compute_access_range.  Specifically in this
> function we have:
> 
> :
>   _1 = *nb_113(D);
>   ubound.86_114 = (integer(kind=8)) _1;
>   stride.88_115 = MAX_EXPR ;
> 
> ...
> 
> :  // thus in loop nest we have _1 > 0
>   if (_1 <= 0)
> goto ; [15.00%]
>   else
> goto ; [85.00%]
> 
> ...
> 
> And in the end, we need to prove:
> 
> ((sizetype) ((unsigned int) _1 + 4294967295) + 1) * 8
>  == (sizetype) stride.88_115 * 8
> 
> We first need to prove:
> ((sizetype) ((unsigned int) _1 + 4294967295) + 1)
>   == (sizetype) _1
> using pre-condition "_1 > 0"
> 
> Then need to prove: MAX_EXPR  == ubound.86_114 also because
> of "_1 > 0".
> 
> I doubt this can be done (without heavy messy code) in GCC now.  Or there 
> might
> be another way out of this?

I think the zeroing stmt can be distributed into a separate loop nest
(up to whavever level we choose) and in the then non-parallelized nest
the memset can stay at the current level.  So distribute

>  do j=1,ny
> jm1=mod(j+ny-2,ny)+1
> jp1=mod(j,ny)+1
> do i=1,nx
>im1=mod(i+nx-2,nx)+1
>ip1=mod(i,nx)+1
>do l=1,nb
>   y(l,i,j,k)=0.0d0
>   do m=1,nb
>  y(l,i,j,k)=y(l,i,j,k)+
>  ;; 
>   enddo
>enddo
> enddo
>  enddo

to

>  do j=1,ny
> jm1=mod(j+ny-2,ny)+1
> jp1=mod(j,ny)+1
> do i=1,nx
>im1=mod(i+nx-2,nx)+1
>ip1=mod(i,nx)+1
>do l=1,nb
>   y(l,i,j,k)=0.0d0
>enddo
> enddo
>  enddo
>  do j=1,ny
> jm1=mod(j+ny-2,ny)+1
> jp1=mod(j,ny)+1
> do i=1,nx
>im1=mod(i+nx-2,nx)+1
>ip1=mod(i,nx)+1
>do l=1,nb
>   do m=1,nb
>  y(l,i,j,k)=y(l,i,j,k)+
>  ;; 
>   enddo
>enddo
> enddo
>  enddo

And then do memset replacement in the first loop.

I think the current cost modeling doesn't consider this because
of the re-use of y.  IIRC this is what my original nest distribution
patches did.

This might be doable by just cost model changes?

[Bug c++/83919] [8 regression] spurious -Wignored-qualifiers warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 43169
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43169&action=edit
gcc8-pr83919.patch

Untested fix.  Seems similar to PR82299, just for a different warning.

[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used

[amker at gcc dot gnu.org]

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

--- Comment #12 from amker at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #11)
> On Thu, 18 Jan 2018, amker at gcc dot gnu.org wrote:
> 
> 
> I think the zeroing stmt can be distributed into a separate loop nest
> (up to whavever level we choose) and in the then non-parallelized nest
> the memset can stay at the current level.  So distribute
> 
> >  do j=1,ny
> > jm1=mod(j+ny-2,ny)+1
> > jp1=mod(j,ny)+1
> > do i=1,nx
> >im1=mod(i+nx-2,nx)+1
> >ip1=mod(i,nx)+1
> >do l=1,nb
> >   y(l,i,j,k)=0.0d0
> >   do m=1,nb
> >  y(l,i,j,k)=y(l,i,j,k)+
> >  ;; 
> >   enddo
> >enddo
> > enddo
> >  enddo
> 
> to
> 
> >  do j=1,ny
> > jm1=mod(j+ny-2,ny)+1
> > jp1=mod(j,ny)+1
> > do i=1,nx
> >im1=mod(i+nx-2,nx)+1
> >ip1=mod(i,nx)+1
> >do l=1,nb
> >   y(l,i,j,k)=0.0d0
> >enddo
> > enddo
> >  enddo
> >  do j=1,ny
> > jm1=mod(j+ny-2,ny)+1
> > jp1=mod(j,ny)+1
> > do i=1,nx
> >im1=mod(i+nx-2,nx)+1
> >ip1=mod(i,nx)+1
> >do l=1,nb
> >   do m=1,nb
> >  y(l,i,j,k)=y(l,i,j,k)+
> >  ;; 
> >   enddo
> >enddo
> > enddo
> >  enddo
> 
Yes, this can be done.  For now, it's disabled because without classifying
zeroing stmt as a builtin partition, it's fused because of shared memory
reference to y(l,i,j,k).  This step can be made by cost model changes.  The
on;y problem is the cost model change doesn't make sense here (without
considering builtin partition stuff, it should be fused, right?)

> And then do memset replacement in the first loop.
I guess this step is equally hard to what I mentioned?  We still need to prove
loops of zeroing statement doesn't leave bubble in memory.
> 
> I think the current cost modeling doesn't consider this because
> of the re-use of y.  IIRC this is what my original nest distribution
> patches did.
> 
> This might be doable by just cost model changes?

[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  ---
On Thu, 18 Jan 2018, amker at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82604
> 
> --- Comment #12 from amker at gcc dot gnu.org ---
> (In reply to rguent...@suse.de from comment #11)
> > On Thu, 18 Jan 2018, amker at gcc dot gnu.org wrote:
> > 
> > 
> > I think the zeroing stmt can be distributed into a separate loop nest
> > (up to whavever level we choose) and in the then non-parallelized nest
> > the memset can stay at the current level.  So distribute
> > 
> > >  do j=1,ny
> > > jm1=mod(j+ny-2,ny)+1
> > > jp1=mod(j,ny)+1
> > > do i=1,nx
> > >im1=mod(i+nx-2,nx)+1
> > >ip1=mod(i,nx)+1
> > >do l=1,nb
> > >   y(l,i,j,k)=0.0d0
> > >   do m=1,nb
> > >  y(l,i,j,k)=y(l,i,j,k)+
> > >  ;; 
> > >   enddo
> > >enddo
> > > enddo
> > >  enddo
> > 
> > to
> > 
> > >  do j=1,ny
> > > jm1=mod(j+ny-2,ny)+1
> > > jp1=mod(j,ny)+1
> > > do i=1,nx
> > >im1=mod(i+nx-2,nx)+1
> > >ip1=mod(i,nx)+1
> > >do l=1,nb
> > >   y(l,i,j,k)=0.0d0
> > >enddo
> > > enddo
> > >  enddo
> > >  do j=1,ny
> > > jm1=mod(j+ny-2,ny)+1
> > > jp1=mod(j,ny)+1
> > > do i=1,nx
> > >im1=mod(i+nx-2,nx)+1
> > >ip1=mod(i,nx)+1
> > >do l=1,nb
> > >   do m=1,nb
> > >  y(l,i,j,k)=y(l,i,j,k)+
> > >  ;; 
> > >   enddo
> > >enddo
> > > enddo
> > >  enddo
> > 
> Yes, this can be done.  For now, it's disabled because without classifying
> zeroing stmt as a builtin partition, it's fused because of shared memory
> reference to y(l,i,j,k).  This step can be made by cost model changes.  The
> on;y problem is the cost model change doesn't make sense here (without
> considering builtin partition stuff, it should be fused, right?)

It might be profitable to distribute away stores that have no dependent
stmts (thus stores from invariants).

Another heuristic would be to never merge builtin partitions with
other partitions because loop optimizations do not handle memory
builtins (the data dependence limitation).  Which might also be a reason
not to handle those as builtins but revert to a non-builtin
classification.

I suppose implementing both and then looking at what distributions
change due to them on say SPEC CPU 2006, classifying each change
as either good or bad is the only way we'd know whether such
cost model change is wanted.

> > And then do memset replacement in the first loop.
> I guess this step is equally hard to what I mentioned?  We still need to prove
> loops of zeroing statement doesn't leave bubble in memory.

No, you'd simply have the i and j loops containing a memset...

[Bug target/65578] FAIL: gcc.target/arm/builtin-bswap-1.c (test for excess errors)

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #9 from Christophe Lyon  ---
Note that I posted this:
https://gcc.gnu.org/ml/gcc-patches/2012-09/msg01501.html
ages ago :-)

[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used

[amker at gcc dot gnu.org]

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

--- Comment #14 from amker at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #13)
> On Thu, 18 Jan 2018, amker at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82604
> > 
> > --- Comment #12 from amker at gcc dot gnu.org ---
> > (In reply to rguent...@suse.de from comment #11)
> > > 
> > Yes, this can be done.  For now, it's disabled because without classifying
> > zeroing stmt as a builtin partition, it's fused because of shared memory
> > reference to y(l,i,j,k).  This step can be made by cost model changes.  The
> > on;y problem is the cost model change doesn't make sense here (without
> > considering builtin partition stuff, it should be fused, right?)
> 
> It might be profitable to distribute away stores that have no dependent
> stmts (thus stores from invariants).
> 
> Another heuristic would be to never merge builtin partitions with
> other partitions because loop optimizations do not handle memory

Together with last sentence of your comment.  IIUC, so what we want to do is
still a builtin partition distribution from the original loop.  The only
difference is now the loop nest of zeroing stmt is distributed into a
loop(outer) of memset call, rather than a single memset call.  Of course if it
would be even better if it can be distributed into a single memset.
Currently such loop nest in this case is not classified as builtin partition.

> builtins (the data dependence limitation).  Which might also be a reason
> not to handle those as builtins but revert to a non-builtin
> classification.
But I don't quite follow this sentence,  why not handle it as builtins?  it is
special, but eventually we want to distribute it into memset (in a loop nest),
right?

Thanks
> 
> I suppose implementing both and then looking at what distributions
> change due to them on say SPEC CPU 2006, classifying each change
> as either good or bad is the only way we'd know whether such
> cost model change is wanted.
> 
> > > And then do memset replacement in the first loop.
> > I guess this step is equally hard to what I mentioned?  We still need to 
> > prove
> > loops of zeroing statement doesn't leave bubble in memory.
> 
> No, you'd simply have the i and j loops containing a memset...

[Bug c++/83923] No destructor called for constructor argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
   Target Milestone|--- |7.3

--- Comment #1 from Jonathan Wakely  ---
This has already been reported and fixed.

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

[Bug target/83920] [nvptx] bad predicate reset

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-18
 Ever confirmed|0   |1

--- Comment #2 from Tom de Vries  ---
Confirmed. The workaround is intended to work on code like this:
...
{   
.reg .u32 %x;   
mov.u32 %x,%tid.x;  
setp.ne.u32 %rnotvzero,%x,0;
 }  

 @%rnotvzero bra Lskip; 
 setp.. %rcond,op1,op2;   
 Lskip: 
 selp.u32 %rcondu32,1,0,%rcond; 
 shfl.idx.b32 %rcondu32,%rcondu32,0,31; 
 setp.ne.u32 %rcond,%rcondu32,0;
...
and adds 'setp.eq.u32 %rcond, 1, 0;' before "bra Lskip". However, if the branch
condition is not calculated in the basic block containing the conditional jump,
then the workaround overwrites the branch condition.

In the case of comment 1, it's the most extreme case: we're neutering an empty
block:
...
@%r341  bra $L33;
$L33:
...
so the condition must be defined elsewhere.

[Bug c++/82560] [7/8 Regression] Temporary object created as a default argument not destructed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||mszyszkowski93 at gmail dot com

--- Comment #9 from Jonathan Wakely  ---
*** Bug 83923 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/83887] [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 3 should be 21, not 18)

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Jan 18 10:59:33 2018
New Revision: 256841

URL: https://gcc.gnu.org/viewcvs?rev=256841&root=gcc&view=rev
Log:
2018-01-18  Richard Biener  

PR tree-optimization/83887
* graphite-scop-detection.c
(scop_detection::get_nearest_dom_with_single_entry): Remove.
(scop_detection::get_nearest_pdom_with_single_exit): Likewise.
(scop_detection::merge_sese): Re-implement with a flood-fill
algorithm that properly finds a SESE region if it exists.

* gcc.dg/graphite/pr83887.c: New testcase.
* gfortran.dg/graphite/pr83887.f90: Likewise.
* gfortran.dg/graphite/pr83887.f: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr83887.c
trunk/gcc/testsuite/gfortran.dg/graphite/pr83887.f
trunk/gcc/testsuite/gfortran.dg/graphite/pr83887.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-scop-detection.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de  ---
On Thu, 18 Jan 2018, amker at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82604
> 
> --- Comment #14 from amker at gcc dot gnu.org ---
> (In reply to rguent...@suse.de from comment #13)
> > On Thu, 18 Jan 2018, amker at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82604
> > > 
> > > --- Comment #12 from amker at gcc dot gnu.org ---
> > > (In reply to rguent...@suse.de from comment #11)
> > > > 
> > > Yes, this can be done.  For now, it's disabled because without classifying
> > > zeroing stmt as a builtin partition, it's fused because of shared memory
> > > reference to y(l,i,j,k).  This step can be made by cost model changes.  
> > > The
> > > on;y problem is the cost model change doesn't make sense here (without
> > > considering builtin partition stuff, it should be fused, right?)
> > 
> > It might be profitable to distribute away stores that have no dependent
> > stmts (thus stores from invariants).
> > 
> > Another heuristic would be to never merge builtin partitions with
> > other partitions because loop optimizations do not handle memory
> 
> Together with last sentence of your comment.  IIUC, so what we want to do is
> still a builtin partition distribution from the original loop.  The only
> difference is now the loop nest of zeroing stmt is distributed into a
> loop(outer) of memset call, rather than a single memset call.  Of course if it
> would be even better if it can be distributed into a single memset.
> Currently such loop nest in this case is not classified as builtin partition.
> 
> > builtins (the data dependence limitation).  Which might also be a reason
> > not to handle those as builtins but revert to a non-builtin
> > classification.
> But I don't quite follow this sentence,  why not handle it as builtins?  it is
> special, but eventually we want to distribute it into memset (in a loop nest),
> right?

Do not handle it as builtins because we cannot handle builtins in data
dependence and we do not want to distribute it into a separate nest
because of data locality.

Needs to be measured ;)

[Bug fortran/83866] [8 Regression] ICE in gfc_release_symbol, at fortran/symbol.c:3087

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-18
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Likely revision r251925. My instrumented compiler gives

==95172==ERROR: AddressSanitizer: heap-use-after-free on address 0x61304780
at pc 0x0001004c0a3f bp 0x7ffeefbfe5d0 sp 0x7ffeefbfe5c8
READ of size 8 at 0x61304780 thread T0
#0 0x1004c0a3e in gfc_restore_last_undo_checkpoint() symbol.c:3647
#1 0x1004c1a6f in gfc_undo_symbols() symbol.c:3727
#2 0x10032047c in reject_statement() parse.c:2547
#3 0x1003205c4 in match_word(char const*, match (*)(), locus*) parse.c:70
#4 0x10032e2a0 in decode_statement() parse.c:565
#5 0x10032f54e in next_free() parse.c:1226
#6 0x10032ff13 in next_statement() parse.c:1458
#7 0x100336433 in parse_spec(gfc_statement) parse.c:3836
#8 0x10033cea2 in parse_progunit(gfc_statement) parse.c:5649
#9 0x10033f1ea in gfc_parse_file() parse.c:6189
#10 0x1004faacc in gfc_be_parse_file() f95-lang.c:204
#11 0x10587f0d0 in compile_file() toplev.c:455
#12 0x105889962 in do_compile() toplev.c:2076
#13 0x107bd1f47 in toplev::main(int, char**) toplev.c:2211
#14 0x107bd73cc in main main.c:39
#15 0x7fff5c0dd114 in start (libdyld.dylib:x86_64+0x1114)

0x61304780 is located 320 bytes inside of 336-byte region
[0x61304640,0x61304790)
freed by thread T0 here:
#0 0x156081020 in wrap_free.part.0 sanitizer_malloc_mac.inc:142
#1 0x1004b0aff in gfc_free_symbol(gfc_symbol*) symbol.c:3061
#2 0x1004b0e4b in gfc_release_symbol(gfc_symbol*) symbol.c:3088
#3 0x1004b12ca in free_sym_tree(gfc_symtree*) symbol.c:3890
#4 0x1004b007f in gfc_free_namespace(gfc_namespace*) symbol.c:4045
#5 0x1004b0a90 in gfc_free_symbol(gfc_symbol*) symbol.c:3054
#6 0x1004b0e4b in gfc_release_symbol(gfc_symbol*) symbol.c:3088
#7 0x1004c162f in gfc_restore_last_undo_checkpoint() symbol.c:3696
#8 0x1004c1a6f in gfc_undo_symbols() symbol.c:3727
#9 0x10032047c in reject_statement() parse.c:2547
#10 0x1003205c4 in match_word(char const*, match (*)(), locus*) parse.c:70
#11 0x10032e2a0 in decode_statement() parse.c:565
#12 0x10032f54e in next_free() parse.c:1226
#13 0x10032ff13 in next_statement() parse.c:1458
#14 0x100336433 in parse_spec(gfc_statement) parse.c:3836
#15 0x10033cea2 in parse_progunit(gfc_statement) parse.c:5649
#16 0x10033f1ea in gfc_parse_file() parse.c:6189
#17 0x1004faacc in gfc_be_parse_file() f95-lang.c:204
#18 0x10587f0d0 in compile_file() toplev.c:455
#19 0x105889962 in do_compile() toplev.c:2076
#20 0x107bd1f47 in toplev::main(int, char**) toplev.c:2211
#21 0x107bd73cc in main main.c:39
#22 0x7fff5c0dd114 in start (libdyld.dylib:x86_64+0x1114)

previously allocated by thread T0 here:
#0 0x156080690 in wrap_calloc sanitizer_malloc_mac.inc:153
#1 0x107b7ee6e in xcalloc xmalloc.c:162
#2 0x1004a7f55 in gfc_new_symbol(char const*, gfc_namespace*) symbol.c:3097
#3 0x1004aa45a in gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) symbol.c:3348
#4 0x1004aba88 in gfc_get_symbol(char const*, gfc_namespace*, gfc_symbol**)
symbol.c:3398
#5 0x1000cfe68 in gfc_match_formal_arglist(gfc_symbol*, int, int, bool)
decl.c:5978
#6 0x1000eb9ad in gfc_match_derived_decl() decl.c:9848
#7 0x100320542 in match_word(char const*, match (*)(), locus*) parse.c:65
#8 0x10032e2a0 in decode_statement() parse.c:565
#9 0x10032f54e in next_free() parse.c:1226
#10 0x10032ff13 in next_statement() parse.c:1458
#11 0x100336433 in parse_spec(gfc_statement) parse.c:3836
#12 0x10033cea2 in parse_progunit(gfc_statement) parse.c:5649
#13 0x10033f1ea in gfc_parse_file() parse.c:6189
#14 0x1004faacc in gfc_be_parse_file() f95-lang.c:204
#15 0x10587f0d0 in compile_file() toplev.c:455
#16 0x105889962 in do_compile() toplev.c:2076
#17 0x107bd1f47 in toplev::main(int, char**) toplev.c:2211
#18 0x107bd73cc in main main.c:39
#19 0x7fff5c0dd114 in start (libdyld.dylib:x86_64+0x1114)

SUMMARY: AddressSanitizer: heap-use-after-free symbol.c:3647 in
gfc_restore_last_undo_checkpoint()
Shadow bytes around the buggy address:
  0x1c2608a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c2608b0: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa
  0x1c2608c0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x1c2608d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c2608e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x1c2608f0:[fd]fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c260900: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c26

[Bug tree-optimization/83887] [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 3 should be 21, not 18)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed for good.

[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used

[amker at gcc dot gnu.org]

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

--- Comment #16 from amker at gcc dot gnu.org ---
I hope it's possible to break the dependence by reordering passes so that
graphite/parallelization could be moved earlier.  There are several issues like
this IIRC.

[Bug fortran/83865] ICE in wide_int_to_tree_1, at tree.c:1567

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-18
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used

[rguenther at suse dot de]

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

--- Comment #17 from rguenther at suse dot de  ---
On Thu, 18 Jan 2018, amker at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82604
> 
> --- Comment #16 from amker at gcc dot gnu.org ---
> I hope it's possible to break the dependence by reordering passes so that
> graphite/parallelization could be moved earlier.  There are several issues 
> like
> this IIRC.

Certainly not for GCC 8.  Also given that parallelization involves
outlining of code this always introduces issues with dependence
analysis due to extra indirections and us not being able to transition
all relevant information to the outlined copy.  So I'd even move
it later... (after vectorization for example).

For this particular case dependence analysis should be enhanced to
also handle memory builtins of course.

[Bug c++/83924] New: ICE: Error reporting routines re-entered with -Wduplicated-branches

[szotsaki at gmail dot com]

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

Bug ID: 83924
   Summary: ICE: Error reporting routines re-entered with
-Wduplicated-branches
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: szotsaki at gmail dot com
  Target Milestone: ---

Example code:

class GenVectorS {};

template
using  VectorS = GenVectorS;

template
void runB(const VectorS<(n > m ? n : m)>)
{}

void runA() {
runB<1, 1>(VectorS<1>{});
}

Command line: 
./g++.exe -Wduplicated-branches code.cpp

Error message:
Internal compiler error: Error reporting routines re-entered.
libbacktrace could not find executable to open

Additional thoughts:
- No error without -Wduplicated-branches.
- No error when <1, 1> is not identical (like <1, 0>).
- No error when you leave out the "using" statement and replace the code to use
a templated version "GenVectorS" everywhere.

Version:
Using built-in specs.
COLLECT_GCC=C:\MinGW\mingw-w64\x86_64-7.1.0-posix-seh-rt_v5-rev2\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/MinGW/mingw-w64/x86_64-7.1.0-posix-seh-rt_v5-rev2/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/7.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-7.1.0/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysroot=/c/mingw710/x86_64-710-posix-seh-rt_v5-rev2/mingw64
--enable-shared --enable-static --disable-multilib
--enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes
--enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto
--enable-graphite --enable-checking=release --enable-fully-dynamic-string
--enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona
--with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/c/mingw710/prerequisites/x86_64-w64-mingw32-static
--with-mpfr=/c/mingw710/prerequisites/x86_64-w64-mingw32-static
--with-mpc=/c/mingw710/prerequisites/x86_64-w64-mingw32-static
--with-isl=/c/mingw710/prerequisites/x86_64-w64-mingw32-static
--with-pkgversion='x86_64-posix-seh-rev2, Built by MinGW-W64 project'
--with-bugurl=https://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-fno-ident -I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev2/mingw64/opt/include
-I/c/mingw710/prerequisites/x86_64-zlib-static/include
-I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2
-pipe -fno-ident
-I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev2/mingw64/opt/include
-I/c/mingw710/prerequisites/x86_64-zlib-static/include
-I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS='
-I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev2/mingw64/opt/include
-I/c/mingw710/prerequisites/x86_64-zlib-static/include
-I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe
-fno-ident -L/c/mingw710/x86_64-710-posix-seh-rt_v5-rev2/mingw64/opt/lib
-L/c/mingw710/prerequisites/x86_64-zlib-static/lib
-L/c/mingw710/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 7.1.0 (x86_64-posix-seh-rev2, Built by MinGW-W64 project)

[Bug c++/80488] Erroneous error "lambda-expression in template argument"

[arbmind at gmail dot com]

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

Andreas Reischuck  changed:

   What|Removed |Added

 CC||arbmind at gmail dot com

--- Comment #1 from Andreas Reischuck  ---
This bug also hit me.

I found this discussion on Stackoverflow:
https://stackoverflow.com/questions/43213997/why-is-gcc-failing-when-using-lambda-for-non-type-template-parameter

And I can report that VS2017 15.5 and clang 6 can compile this code:

  template
  void x() {}

  void test() {
x<[] {}>();
  }

template is not yet supported.

[Bug c++/83924] ICE: Error reporting routines re-entered with -Wduplicated-branches

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-18
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
This was fixed on trunk with

commit 301c8f8fce4125a095df4316cd75f5fe2fdf2c7f
Author: mpolacek 
Date:   Wed Jan 10 17:05:14 2018 +

PR c++/82541
* call.c (build_conditional_expr_1): Check complain before warning.
* pt.c (tsubst_copy_and_build) : Suppress
-Wduplicated-branches.

* g++.dg/warn/Wduplicated-branches4.C: New test.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@256441
138bc75d-0d04-0410-961f-82ee72b054a4

I think the call.c hunk is enough to fix it.

[Bug c++/83160] [8 regression] lvalue required as unary ‘&’ operand

[nathan at gcc dot gnu.org]

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

--- Comment #5 from Nathan Sidwell  ---
Author: nathan
Date: Thu Jan 18 11:53:50 2018
New Revision: 256842

URL: https://gcc.gnu.org/viewcvs?rev=256842&root=gcc&view=rev
Log:
PR c++/83160] local ref to capture

https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01638.html
PR c++/83160
* cp-tree.h (mark_use): Declare.
* expr.c (mark_use): Make extern.
* call.c (direct_reference_binding): Set inner conv's
rvaluedness_matches_p, if it is an identity.
(convert_like_real): Mark lvalue or rvalue use for identity as
rvaledness_matches_p demands.

PR c++/83160
* g++.dg/cpp0x/pr83160.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr83160.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/83160] [8 regression] lvalue required as unary ‘&’ operand

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #6 from Nathan Sidwell  ---
Fixed r256842.

[Bug debug/83728] [8 regression] FAIL: gcc.dg/guality/pr68037-1.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
So, one problem here is that the debug marker for line 33 is moved by sched2
too early (unnecessarily), before the prologue, before statement frontiers
introduction we'd break only after the prologue.
Perhaps we should tweak the scheduler so that it attempts harder not to move
debug markers before the prologue, unless really necessary?

And another bug which I'll try to fix is that the .debug_frame generated with
-fdwarf2-cfi-asm is wrong on the very first insn in the interrupt function, for
-fno-dwarf2-cfi-asm it is right.  Apparently the interrupt attribute functions
have CFI with a different initial offset, the CIE with -fdwarf2-cfi-asm has
initial offset of cfa-8 like normal functions, and right after the very first
insn in the interrupt function fn, which is a push, the offset becomes cfa-24,
while with -fno-dwarf2-cfi-asm we start with cfa-16 in the CIE and after the
push get cfa-16.

[Bug bootstrap/48879] Compilation cannot find file asm/errno.h

[gjl at gcc dot gnu.org]

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

--- Comment #9 from Georg-Johann Lay  ---
Hi, installing linux-libc-dev:i386 resolved this issue for me (linux-libc-dev
was already installed).

[Bug target/83920] [nvptx] bad predicate reset

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
(In reply to cesar from comment #0)
> I think there
> might be other PTX JIT bugs lurking here, because the test program still
> works as intended.

I can make it fail on trunk, by changing the workaround to initialize with one
instead of zero:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 86fc13f4fc0..ab03f3b5fe7 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -4097,7 +4097,7 @@ nvptx_single (unsigned mask, basic_block from,
basic_block to)
 There is nothing in the PTX spec to suggest that this is wrong, or
 to explain why the extra initialization is needed.  So, we
classify
 it as a JIT bug, and the extra initialization as workaround.  */
- emit_insn_before (gen_movbi (pvar, const0_rtx),
+ emit_insn_before (gen_movbi (pvar, constm1_rtx),
bb_first_real_insn (from));
 #endif
  emit_insn_before (nvptx_gen_vcast (pvar), tail);
...
[ Note that there are no regressions with this patch, so the test-case triggers
something not present in the current trunk test set. ]


Likewise, reversing the if-then-else order in gemm.f90 makes the testcase fail
on trunk without this patch.


So, this has nothing to do with PTX JIT bugs.

[Bug c++/81013] [7/8 Regression] ICE with invalid union in class hierarchy

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|paolo.carlini at oracle dot com|
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #2 from Paolo Carlini  ---
Mine.

[Bug other/70268] add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE()

[boris at gcc dot gnu.org]

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

--- Comment #16 from boris at gcc dot gnu.org ---
Author: boris
Date: Thu Jan 18 13:17:37 2018
New Revision: 256847

URL: https://gcc.gnu.org/viewcvs?rev=256847&root=gcc&view=rev
Log:
Add ability to remap file names in __FILE__, etc (PR other/70268)

This commit adds the -fmacro-prefix-map option that allows remapping of file
names in __FILE__, __BASE_FILE__, and __builtin_FILE(), similar to how
-fdebug-prefix-map allows to do the same for debug information.

Additionally, it adds -ffile-prefix-map which can be used to specify both
mappings with a single option (and, should we need to add more -f*-prefix-map
options in the future, those as well).

libcpp/ChangeLog:

2018-01-18  Boris Kolpackov  

PR other/70268
* include/cpplib.h (cpp_callbacks::remap_filename): New callback.
* libcpp/macro.c (_cpp_builtin_macro_text): Call remap_filename for
__FILE__ and __BASE_FILE__.


gcc/ChangeLog:

2018-01-18  Boris Kolpackov  

PR other/70268
* common.opt: (-ffile-prefix-map): New option.
* opts.c (common_handle_option): Defer it.
* opts-global.c (handle_common_deferred_options): Handle it.
* debug.h (remap_debug_filename, add_debug_prefix_map): Move to...
* file-prefix-map.h: New file.
(remap_debug_filename, add_debug_prefix_map): ...here.
(add_macro_prefix_map, add_file_prefix_map, remap_macro_filename): New.
* final.c (debug_prefix_map, add_debug_prefix_map
remap_debug_filename): Move to...
* file-prefix-map.c: New file.
(file_prefix_map, add_prefix_map, remap_filename) ...here and rename,
generalize, get rid of alloca(), use strrchr() instead of strchr().
(add_macro_prefix_map, add_debug_prefix_map, add_file_prefix_map):
Implement in terms of add_prefix_map().
(remap_macro_filename, remap_debug_filename): Implement in term of
remap_filename().
* Makefile.in (OBJS, PLUGIN_HEADERS): Add new files.
* builtins.c (fold_builtin_FILE): Call remap_macro_filename().
* dbxout.c: Include file-prefix-map.h.
* varasm.c: Likewise.
* vmsdbgout.c: Likewise.
* xcoffout.c: Likewise.
* dwarf2out.c: Likewise plus omit new options from DW_AT_producer.
* doc/cppopts.texi (-fmacro-prefix-map): Document.
* doc/invoke.texi (-ffile-prefix-map): Document.
(-fdebug-prefix-map): Update description.


gcc/c-family/ChangeLog:

2018-01-18  Boris Kolpackov  

PR other/70268
* c-family/c.opt (-fmacro-prefix-map): New option.
* c-family/c-opts.c (c_common_handle_option): Handle it.
* c-family/c-lex.c (init_c_lex): Set remap_filename cpp callback.
* c-family/c-ppoutput.c (init_pp_output): Likewise.


gcc/testsuite/ChangeLog:

2018-01-18  Boris Kolpackov  

PR other/70268
* c-c++-common/ffile-prefix-map.c: New test.
* c-c++-common/fmacro-prefix-map.c: New test.
* c-c++-common/cpp/ffile-prefix-map.c: New test.
* c-c++-common/cpp/fmacro-prefix-map.c: New test.


Added:
trunk/gcc/file-prefix-map.c
trunk/gcc/file-prefix-map.h   (with props)
trunk/gcc/testsuite/c-c++-common/cpp/ffile-prefix-map.c
trunk/gcc/testsuite/c-c++-common/cpp/fmacro-prefix-map.c
trunk/gcc/testsuite/c-c++-common/ffile-prefix-map.c
trunk/gcc/testsuite/c-c++-common/fmacro-prefix-map.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/builtins.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-lex.c
trunk/gcc/c-family/c-opts.c
trunk/gcc/c-family/c-ppoutput.c
trunk/gcc/c-family/c.opt
trunk/gcc/common.opt
trunk/gcc/dbxout.c
trunk/gcc/debug.h
trunk/gcc/doc/cppopts.texi
trunk/gcc/doc/invoke.texi
trunk/gcc/dwarf2out.c
trunk/gcc/final.c
trunk/gcc/opts-global.c
trunk/gcc/opts.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c
trunk/gcc/vmsdbgout.c
trunk/gcc/xcoffout.c
trunk/libcpp/ChangeLog
trunk/libcpp/include/cpplib.h
trunk/libcpp/macro.c

Propchange: trunk/gcc/file-prefix-map.h
('svn:eol-style' added)

Propchange: trunk/gcc/file-prefix-map.h
('svn:keywords' added)

[Bug target/83920] [nvptx] bad predicate reset

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
(In reply to cesar from comment #0)
> the underlying problem is present
> in og7 and impacts da-1.c). 

That's a failure I did not manage to reproduce. For me, at commit
b4dd21b9a1f9f499c613b55225cad689b7928a7f "Use functional parameters for data
mappings in OpenACC child functions", that test passes, also when using -O3.

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[alexey.salmin at gmail dot com]

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

--- Comment #46 from Alexey Salmin  ---
Tested the latest patch, behavior looks very reasonable even in tricky cases.

1) No warning, gcd(12, 8) == 4
struct tuple_t {
char c[12];
__int128_t i;
} __attribute__((packed, aligned(8)));

typedef struct unaligned_int128_t_ {
__int128_t value;
} __attribute__((packed, aligned(4))) unaligned_int128_t;

struct tuple_t p = {0, 1};
unaligned_int128_t *addr = (unaligned_int128_t *)(&p.i);

2) Gives a warning, gcd(10, 8) < 4
struct tuple_t {
char c[10];
__int128_t i;
} __attribute__((packed, aligned(8)));

typedef struct unaligned_int128_t_ {
__int128_t value;
} __attribute__((packed, aligned(4))) unaligned_int128_t;

struct tuple_t p = {0, 1};
unaligned_int128_t *addr = (unaligned_int128_t *)(&p.i);

[Bug libgomp/83589] [nvptx] mode-transitions.c and private-variables.{c,f90} execution FAILs

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Using the patch from PR83920 comment 3 and testing libgomp.oacc-c/c.exp makes
the  libgomp.oacc-c/c.exp failures of this PR go away.

So, this might be a duplicate.

[Bug target/83920] [nvptx] bad predicate reset

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
This ( PR83589 - "[nvptx] mode-transitions.c and private-variables.{c,f90}
execution FAILs at GOMP_NVPTX_JIT=-O0" ) may be a duplicate.

[Bug ipa/82256] [6/7/8 Regression] clones created by create_version_clone_with_body are not observable to insertion hooks

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Jan Hubicka  ---
I am going to test the patch against mainline and commit it.  However about
backporting, can you produce some issue with this bug?

[Bug c/83925] New: [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[polyakova.marina69 at gmail dot com]

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

Bug ID: 83925
   Summary: [SPARC/Solaris] __int128 aligned(8) as function
argument is passed in wrong register
   Product: gcc
   Version: 5.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: polyakova.marina69 at gmail dot com
  Target Milestone: ---

Created attachment 43170
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43170&action=edit
preprocessed file for PG_ALIGN_128=8

If we define a new type int128a as __int128 __attribute__((aligned(8))), and
you pass it as not the first function argument, its value in the function may
be incorrect. See the output of the test program:

$ gcc -D PG_ALIGN_128=8 -m64 -o int128test2 int128test2.c
$ ./int128test2
basic aritmetic OK
pass int 16 FAILED
pass uint 16 FAILED
pass int 32 FAILED
pass int 64 FAILED
pass int 128 OK

(see its preprocessed file int128test2_8.i as an attachment)

When the alignment is 16, everything is fine:

$ gcc -D PG_ALIGN_128=16 -m64 -o int128test2 int128test2.c
$ ./int128test2
basic aritmetic OK
pass int 16 OK
pass uint 16 OK
pass int 32 OK
pass int 64 OK
pass int 128 OK

As it turns out, Sparc GCC passes function arguments via register ring which is
referenced as %on in the calling code and as %in in function. And somehow it
happens that alignment attribute of typedef affects access to arguments in the
function, but doesn't affect how regiser ring is filled before call.

the system type: sparc-sun-solaris2.10

the options given when GCC was configured/built:
/home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.5.0/configure
--prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin
--sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec --datadir=/opt/csw/share
--sysconfdir=/etc/opt/csw --sharedstatedir=/opt/csw/share
--localstatedir=/var/opt/csw --libdir=/opt/csw/lib
--infodir=/opt/csw/share/info --includedir=/opt/csw/include
--mandir=/opt/csw/share/man --enable-cloog-backend=isl --enable-java-awt=xlib
--enable-languages=ada,c,c++,fortran,go,java,objc --enable-libada
--enable-libssp --enable-nls --enable-objc-gc --enable-threads=posix
--program-suffix=-5.5 --with-cloog=/opt/csw --with-gmp=/opt/csw
--with-included-gettext --with-ld=/usr/ccs/bin/ld --without-gnu-ld
--with-libiconv-prefix=/opt/csw --with-mpfr=/opt/csw --with-ppl=/opt/csw
--with-system-zlib=/opt/csw --with-as=/usr/ccs/bin/as --without-gnu-as

[Bug middle-end/60725] [-Wreturn-type] false positive in trivial switch

[egallager at gcc dot gnu.org]

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

--- Comment #8 from Eric Gallager  ---
Worth returning to this issue now that -Wreturn-type is enabled by default for
gcc8.

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ABI
 Target||sparc-solaris
  Component|c   |target

--- Comment #1 from Richard Biener  ---
Note GCC 5 is no longer maintained - can you test a newer version?

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[polyakova.marina69 at gmail dot com]

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

--- Comment #2 from Марина Полякова  ---
No, I can't because pkgutil has only gcc 4 or 5 :-(

[Bug target/83926] New: ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633

[willschm at gcc dot gnu.org]

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

Bug ID: 83926
   Summary: ICE during RTL pass: ira, in
elimination_costs_in_insn, at reload1.c:3633
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: willschm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43171
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43171&action=edit
simplified testcase

Failure seen on Power8 BE, discovered while reworking some tests to disable
gimple-folding.   

/home/willschm/gcc/build/gcc-mainline-baseline/gcc/xgcc
-B/home/willschm/gcc/build/gcc-mainline-baseline/gcc/
/home/willschm/gcc/testme.c  -fno-diagnostics-show-caret
-fdiagnostics-color=never -mcpu=power8 -O0 -ffat-lto-objects -S -m32  -o
testme.s -dap -mno-fold-gimple
gimple folding of rs6000 builtins has been disabled.
during RTL pass: ira
dump file: testme.c.278r.ira
/home/willschm/gcc/testme.c: In function ‘main’:
/home/willschm/gcc/testme.c:19:1: internal compiler error: in
elimination_costs_in_insn, at reload1.c:3633
0x108a05af elimination_costs_in_insn
/home/willschm/gcc/gcc-mainline-baseline/gcc/reload1.c:3630
0x108a8be7 calculate_elim_costs_all_insns()
/home/willschm/gcc/gcc-mainline-baseline/gcc/reload1.c:1607
0x106f79b7 ira_costs()
/home/willschm/gcc/gcc-mainline-baseline/gcc/ira-costs.c:2249
0x106ef2d3 ira_build()
/home/willschm/gcc/gcc-mainline-baseline/gcc/ira-build.c:3421
0x106e30af ira
/home/willschm/gcc/gcc-mainline-baseline/gcc/ira.c:5292
0x106e30af execute
/home/willschm/gcc/gcc-mainline-baseline/gcc/ira.c:5603
Please submit a full bug report,

[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633

[willschm at gcc dot gnu.org]

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

Will Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #1 from Will Schmidt  ---
Created attachment 43172
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43172&action=edit
ira dump

ira dump.

[Bug fortran/83927] New: Type-Bound Procedure on element of Derived Type PARAMETER Array

[adam at aphirst dot karoo.co.uk]

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

Bug ID: 83927
   Summary: Type-Bound Procedure on element of Derived Type
PARAMETER Array
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adam at aphirst dot karoo.co.uk
  Target Milestone: ---

Created attachment 43173
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43173&action=edit
short program demonstrating the issue

I've tried to minimise the code sample as much as possible.
https://gist.github.com/aphirst/5028d3a0ec1c15011e2b1181e4f1a7b5

I have some arrays (one a variable, one a PARAMETER) of Type(MyType), and a
bound procedure %MyFunc() on that type.

Calls to that procedure using specific elements of that array, say
v(1)%MyFunc(), fail, complaining:

Error: Can't convert TYPE(mytype) to REAL(4) at (1)

However, if I replace those calls with identical ones to a parameter which is
scalar but otherwise identical (shown in the code in comments), it compiles and
runs just fine.

It strikes me as odd that a single element of an array works differently to a
scalar. The same array syntax DOES work when used on a variable array, and also
on a PARAMETER scalar, so the issue seems to be somehow related to the
combination of PARAMETER and array for the type-bound procedure logic.

I'm aware that there are other issues regarding PARAMETER arrays, including
#59298 which I reported quite a while ago.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298

gcc version 7.2.1 20171224 (GCC), Arch Linux (x86_64)

If there's any further info which would be useful, please don't hesitate to
ask.

[Bug lto/83816] [6/7 Regression] lto1: internal compiler error: compressed stream: data error

[olegendo at gcc dot gnu.org]

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

--- Comment #17 from Oleg Endo  ---
(In reply to Richard Biener from comment #15)
> 
> I can reproduce it:
> 

Nice.

(In reply to Richard Biener from comment #16)
> Note your testcase only reproduces on the GCC 6 branch.  It is expected that
> the issue happens because of some exact length of the uncompressed or
> compressed section or maybe even the actual contents...

This particular case, yes.  However, I ran into this originally with GCC 7. 
During app development GCC 7 started to bail out while GCC 6 was working OK. 
So I switched back to GCC 6 and after some more app development, that one
started bailing out and GCC 7 does not on that case.

So I'd assume the issue is present in all versions.


> 
> Do you run into this very often?
> 

No, I can't say often.  But it surely is very annoying.  And when it happens
the only practical fix is to turn off LTO, which has a significant negative
impact on the code size.


> It may be possible to extract a "zlib testcase" ... maybe it is a genuine
> bug in it?  (however unlikely that is...)

Somehow I doubt that.
I'm now adding some logging around the code in lto-compress.c but so far I'm
not getting any useful info out of it.  The decompression fails right at the
first block in the stream.

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[polyakova.marina69 at gmail dot com]

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

--- Comment #3 from Марина Полякова  ---
(In reply to Richard Biener from comment #1)
> Note GCC 5 is no longer maintained - can you test a newer version?

No, I can't because pkgutil has only gcc 4 or 5 :-(

[Bug debug/83728] [8 regression] FAIL: gcc.dg/guality/pr68037-1.c

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
That latter bug has been introduced with PR79793.

[Bug target/82941] Missing vzeroupper with -march=skylake-avx512 -O2

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82941
Bug 82941 depends on bug 82942, which changed state.

Bug 82942 Summary: Generate vzeroupper with -mavx512f -mno-avx512er -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82942

   What|Removed |Added

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

[Bug target/82942] Generate vzeroupper with -mavx512f -mno-avx512er -O2

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #10 from H.J. Lu  ---
Fixed for GCC 8 and on GCC 6/7 branches.

[Bug target/82941] Missing vzeroupper with -march=skylake-avx512 -O2

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #5 from H.J. Lu  ---
Fixed for GCC 8 and GCC 6/7 branches,

[Bug debug/83728] [8 regression] FAIL: gcc.dg/guality/pr68037-1.c

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #2)
> So, one problem here is that the debug marker for line 33 is moved by sched2
> too early (unnecessarily), before the prologue, before statement frontiers
> introduction we'd break only after the prologue.
> Perhaps we should tweak the scheduler so that it attempts harder not to move
> debug markers before the prologue, unless really necessary?
> 
> And another bug which I'll try to fix is that the .debug_frame generated
> with -fdwarf2-cfi-asm is wrong on the very first insn in the interrupt
> function, for -fno-dwarf2-cfi-asm it is right.  Apparently the interrupt
> attribute functions have CFI with a different initial offset, the CIE with
> -fdwarf2-cfi-asm has initial offset of cfa-8 like normal functions, and
> right after the very first insn in the interrupt function fn, which is a
> push, the offset becomes cfa-24,
> while with -fno-dwarf2-cfi-asm we start with cfa-16 in the CIE and after the
> push get cfa-16.

Is this related to PR 81570?

[Bug debug/83728] [8 regression] FAIL: gcc.dg/guality/pr68037-1.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 43174
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43174&action=edit
gcc8-pr83728.patch

Untested fix.  Apparently the bug is in there even with -fno-dwarf2-cfi-asm, in
short, in both cases there is just one set of initial cfi insns in the CIE(s),
and furthermore GAS has it hardcoded when using .cfi_startproc.  So, if some
function needs a different initial offset, it needs to emit a CFI insn for that
at the start of the function.

[Bug c++/83928] New: implicit conversion of literal class type to unscoped enumeration can not be used as array size

[smw at gcc dot gnu.org]

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

Bug ID: 83928
   Summary: implicit conversion of literal class type to unscoped
enumeration can not be used as array size
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: smw at gcc dot gnu.org
  Target Milestone: ---

[expr.const]/6 says "If an expression of literal class type is used in a
context where an integral constant expression is required, then that expression
is contextually implicitly converted (Clause 4) to an integral or unscoped
enumeration type and the selected conversion function shall be constexpr."

That works great, except when trying to use that constexpr value in an array
declaration.

A code example speaks louder than tortured English can scream.


  // Case 1: literal class type with implicit coversion to integral expression
  struct LiteralClassTypeInt
  {
constexpr LiteralClassTypeInt(int i) : val(i) { }
constexpr operator int() const { return val; }
  private:
int val;
  };

  template struct X { };

  constexpr LiteralClassTypeInt lct_int = 42;
  X x_int;   // OK: implicit conversion to integral expression
  int int_index[lct_int]; // OK: implicitly converted to integral expression

  // Case 2: Unscoped enumeration
  enum E { three = 3 };
  int eee[three]; // OK: unscoped enumeration is allowed here

  // Case 3: literal class type with implicit conversion to unscoped enum
  struct LiteralClassTypeEnum
  {
constexpr LiteralClassTypeEnum(E e): val(e) { }
constexpr operator E() const { return val; }
  private:
E val;
  };

  constexpr LiteralClassTypeEnum lct_enum(three);
  X x_enum;   // OK!
  int enum_index[lct_enum]; // buggerit

All of ICC, LLVM, and MSVC accept the above code as-is.  GCC (all versions
tested up to and including 8.0.1 20120117 (experimental)) give the following
error.

32 : :32:24: error: size of array 'enum_index' has non-integral type
'const LiteralClassTypeEnum'
 int enum_index[lct_enum]; // buggerit
^
Compiler returned: 1

[Bug ipa/83619] [8 Regression] ICE in inliner: caller edge count does not match BB count

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
Author: hubicka
Date: Thu Jan 18 15:57:48 2018
New Revision: 256850

URL: https://gcc.gnu.org/viewcvs?rev=256850&root=gcc&view=rev
Log:

PR ipa/83619
* g++.dg/torture/pr83619.C: New testcase.
* cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Update edge
frequencies.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr83619.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/83928] implicit conversion of literal class type to unscoped enumeration can not be used as array size

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-18
 Ever confirmed|0   |1

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Rainer, can you please test current trunk?  Thanks.

[Bug ipa/83619] [8 Regression] ICE in inliner: caller edge count does not match BB count

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Hubicka  ---
Fixed.

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #12 from Eric Botcazou  ---
I can reproduce with a cross-compiler on x86-64/Linux.

[Bug ipa/82256] [6/7/8 Regression] clones created by create_version_clone_with_body are not observable to insertion hooks

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

[Bug c++/83929] New: implicit conversion of literal class type can not be used as bit-field length

[smw at gcc dot gnu.org]

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

Bug ID: 83929
   Summary: implicit conversion of literal class type can not be
used as bit-field length
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: smw at gcc dot gnu.org
  Target Milestone: ---

[expr.const]/3 says "An integral constant expression is an expression of
integral or unscoped enumeration type, implicitly converted to a prvalue, where
the converted expression is a core constant expression. [ Note: Such
expressions
may be used as array bounds (8.3.4, 5.3.4), as bit-field lengths (9.6), as
enumerator initializers if the underlying type is not fixed (7.2), and as
alignments (7.6.2). — end note ]"

[expr.const]/6 says "If an expression of literal class type is used in a
context where an integral constant expression is required, then that expression
is contextually implicitly converted (Clause 4) to an integral or unscoped
enumeration type and the selected conversion function shall be constexpr."

That works on ICC, LLVM, MSVC, and other compilers, but


struct LiteralClassType
{
  constexpr LiteralClassType(int i) : val(i) { }
  constexpr operator int() const { return val; }
private:
  int val;
};

constexpr LiteralClassType field_width(3);

struct StructWithBitfields
{
int f1:field_width;
};

will give the following error under GCC (all versions tested).

14 : :14:16: error: width of bit-field 'f1' has non-integral type
'const LiteralClassType'
 int f1:field_width;
^~~
Compiler returned: 1

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  ---
Created attachment 43175
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43175&action=edit
unpreprocessed input

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-18
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Rainer Orth  ---
The failure still happens indeed, but only at -O0, -O and -O2 are fine.

[Bug middle-end/81443] [7/8 regression] build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
   Target Milestone|--- |7.3
Summary|gcc-7.1.0/MIPS N32: |[7/8 regression]
   |build/genrecog.o: virtual   |build/genrecog.o: virtual
   |memory exhausted: Cannot|memory exhausted: Cannot
   |allocate memory |allocate memory

--- Comment #13 from Eric Botcazou  ---
It's an unbounded recursion during combining between cached_num_sign_bit_copies
and num_sign_bit_copies1.

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
128-bit types requite 128-bit alignment on SPARC64 so we cannot support that.

[Bug ipa/82256] [6/7/8 Regression] clones created by create_version_clone_with_body are not observable to insertion hooks

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka  ---
Author: hubicka
Date: Thu Jan 18 16:26:54 2018
New Revision: 256853

URL: https://gcc.gnu.org/viewcvs?rev=256853&root=gcc&view=rev
Log:

PR ipa/82256
patch by PaX Team
* cgraphclones.c (cgraph_node::create_version_clone_with_body):
Fix call of call_cgraph_insertion_hooks.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphclones.c

[Bug ipa/82107] [6/7/8 Regression] O2 optimisation on amd64 leads to error

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #4 from Jan Hubicka  ---
Hmm, so the problem is not merging two comdat functions, but merging a function
inlined into comdat into call to different comdat.
This would suggest that merging non-comdat into comdat is not a safe thing to
do?

Honza

[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher

[arnd at linaro dot org]

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

--- Comment #6 from Arnd Bergmann  ---
Created attachment 43177
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43177&action=edit
Single-file version of aes benchmark

I've managed to condense the 'openssl speed aes-256-cbc' test into a single
file now:

$ x86_64-linux-gcc-7.2.1 -Wall -O2 aes_test.c -o aes_test
$ time ./aes_test
real0m4.499s
user0m4.498s
sys 0m0.000s

$ x86_64-linux-gcc-7.2.1 -Wall -O2 aes_test.c -o aes_test -fno-code-hoisting
$ time ./aes_test
real0m4.135s
user0m4.134s
sys 0m0.000s

The test is hardcoded to do 10 runs of of 8192 bytes, so on my 3.1GHz CPU
that translates cyles:
$ echo $[4999 * 31000  / 81920]
1891 # 18.91 cycles
$ echo $[4135 * 31000  / 81920]
1564 # 15.6 cycles

Similar results with gcc-8.0.0:

$ x86_64-linux-gcc-8.0.0 -Wall -O2 aes_test.c -o aes_test
$ time ./aes_test
real0m4.471s
user0m4.470s
sys 0m0.000s

$ x86_64-linux-gcc-8.0.0 -Wall -O2 aes_test.c -o aes_test -fno-code-hoisting
$ time ./aes_test
real0m4.052s
user0m4.052s
sys 0m0.000s

Hope that helps

[Bug target/83920] [nvptx] bad predicate reset

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries  ---
(In reply to Tom de Vries from comment #3)
> Likewise, reversing the if-then-else order in gemm.f90 makes the testcase
> fail on trunk without this patch.

Minimal version:
...
! { dg-do run } 

subroutine gemm (BETA, C)
  real ::  C(100,100)
  integer :: i, j, l
  real, parameter :: one = 1.0
  real :: beta

  !$acc parallel copy(c(1:100,1:100)) num_gangs(2)  
  !$acc loop gang   
  do j = 1, 100
 if (beta /= one) then
!$acc loop vector   
do i = 1, 100
   C(i,j) = 0.0
end do
 end if
  end do
  !$acc end parallel
end subroutine gemm

program test_gemm
  real :: c(100,100), beta
  beta = 0.0
  c(:,:) = 1.0
  call gemm (beta, c)
  if (c(1,1) /= 0.0) call abort ()
end program test_gemm
...

Passes at O0, fails at O1 and higher.

[Bug target/82964] gfortran.dg/class_array_1.f03 regression since r254388

[wilco at gcc dot gnu.org]

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

--- Comment #5 from Wilco  ---
Author: wilco
Date: Thu Jan 18 16:37:44 2018
New Revision: 256854

URL: https://gcc.gnu.org/viewcvs?rev=256854&root=gcc&view=rev
Log:
[AArch64] Fix fp16 test failures after PR82964 fix

This fixes test failures in gcc.target/aarch64/f16_mov_immediate_*.c
after fixing PR82964.  The check for a scalar floating point constant
didn't include 16-bit floating point modes, so use GET_MODE_CLASS
instead.

gcc/
PR target/82964
* config/aarch64/aarch64.c (aarch64_legitimate_constant_p):
Use GET_MODE_CLASS for scalar floating point.

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

[Bug middle-end/61037] array-bounds false positive

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org
  Known to work||5.1.0, 6.3.0, 7.2.0
  Known to fail||4.9.3

--- Comment #2 from Martin Sebor  ---
It was fixed by r209862 in GCC 4.10.0 (or 5.1.0).

[Bug c++/80956] [7/8 Regression] ICE with abstract class vector

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase:
namespace std {
template  class initializer_list;
}
template  struct B { B (std::initializer_list); };
struct C { virtual int foo (); };
struct D : C {} d { B { D {} } };

Perhaps related to PR83227?

[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

  Attachment #43177|0   |1
is obsolete||

--- Comment #7 from Arnd Bergmann  ---
Created attachment 43178
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43178&action=edit
Single-file version of aes benchmark (shorter)

I decided to strip the test case a bit more down by removing the decryption
side that was unused, and checked that nothing else has changed.

[Bug target/83920] [nvptx] bad predicate reset

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
(In reply to Tom de Vries from comment #6)
> (In reply to Tom de Vries from comment #3)
> > Likewise, reversing the if-then-else order in gemm.f90 makes the testcase
> > fail on trunk without this patch.
> 
> Minimal version:

An even more minimal c version:
...
/* { dg-do run } */

extern void abort (void);

#define n 10

static void __attribute__((noinline)) __attribute__((noclone))
gemm (int beta, int *c)
{
  #pragma acc parallel copy(c[0:(n * n) - 1]) num_gangs(2)
  #pragma acc loop gang
  for (int j = 0; j < n; ++j)
if (beta != 1)
  {
#pragma acc loop vector
for (int i = 0; i < n; ++i)
  c[i + (j * n)] = 0;
  }
}

int
main (void)
{
  int c[n * n];
  c[0] = 1;
  gemm (0.0, c);
  if (c[0] != 0)
abort ();
}
...

Passes at O0, fails at O2.

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[tgl at sss dot pgh.pa.us]

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

Tom Lane  changed:

   What|Removed |Added

 CC||tgl at sss dot pgh.pa.us

--- Comment #8 from Tom Lane  ---
(In reply to Eric Botcazou from comment #7)
> 128-bit types requite 128-bit alignment on SPARC64 so we cannot support that.

Fair enough, but wouldn't it be a good idea to throw an error for the alignment
atttribute, rather than silently generating incorrect code?

[Bug c++/81013] [7/8 Regression] ICE with invalid union in class hierarchy

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Jan 18 17:11:43 2018
New Revision: 256856

URL: https://gcc.gnu.org/viewcvs?rev=256856&root=gcc&view=rev
Log:
/cp
2018-01-18  Paolo Carlini  

PR c++/81013
* decl.c (xref_basetypes): Early return upon error about derived
union.

/testsuite
2018-01-18  Paolo Carlini  

PR c++/81013
* g++.dg/inherit/union3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/inherit/union3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/81013] [7 Regression] ICE with invalid union in class hierarchy

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE with   |[7 Regression] ICE with
   |invalid union in class  |invalid union in class
   |hierarchy   |hierarchy

--- Comment #4 from Paolo Carlini  ---
Fixed for 8.1.0.

[Bug c++/83875] [feature request] target_clones compatible SIMD capability/length check

[roland at rschulz dot eu]

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

--- Comment #8 from Roland Schulz  ---
I would suggest that:
- inside multi-versioned (target_clones/target) function it depends on the
active target
- inside a constexpr context (function/variable, your examples) or
always_inline function it depends on the caller
- otherwise returns the default target

I assume that this should result in always returning the target being used.

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Given the issues we had on ARM, AArch64 (see exempli gratia PR65956 and
associated discussions), et cetera with overaligned/underaligned scalars, I
think the right thing is not to consider alignment for the argument passing and
return value passing decisions at least for scalars.  One can always call a
function with a scalar argument expecting some alignment and callee expecting
different etc.
So, any reason why e.g. in this case the __int128_t arguments shouldn't be
passed always the same, e.g. like normally aligned __int128_t?

[Bug c++/83929] implicit conversion of literal class type can not be used as bit-field length

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-18
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Also valid (see also PR 83928)

[Bug target/83930] New: [7/8 Regression] ICE: RTL check: expected code 'const_int', have 'mem' in simplify_binary_operation_1, at simplify-rtx.c:3302

[zsojka at seznam dot cz]

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

Bug ID: 83930
   Summary: [7/8 Regression] ICE: RTL check: expected code
'const_int', have 'mem' in
simplify_binary_operation_1, at simplify-rtx.c:3302
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

RTL checking might be needed to reproduce this.

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Og -fno-tree-ccp -mavx512f testcase.c 
testcase.c:10:1: warning: always_inline function might not be inlinable
[-Wattributes]
 foo (void)
 ^~~
during RTL pass: combine
testcase.c: In function 'foo':
testcase.c:13:1: internal compiler error: RTL check: expected code 'const_int',
have 'mem' in simplify_binary_operation_1, at simplify-rtx.c:3414
 }
 ^
0x675dce rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/repo/gcc-trunk/gcc/rtl.c:844
0x681a5b simplify_binary_operation_1
/repo/gcc-trunk/gcc/simplify-rtx.c:3414
0xdaf9e5 simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/simplify-rtx.c:2171
0x166457f combine_simplify_rtx
/repo/gcc-trunk/gcc/combine.c:5682
0x1669ec7 subst
/repo/gcc-trunk/gcc/combine.c:5604
0x1669bed subst
/repo/gcc-trunk/gcc/combine.c:5542
0x1669807 subst
/repo/gcc-trunk/gcc/combine.c:5471
0x166be6e try_combine
/repo/gcc-trunk/gcc/combine.c:3354
0x1675334 combine_instructions
/repo/gcc-trunk/gcc/combine.c:1299
0x1675334 rest_of_handle_combine
/repo/gcc-trunk/gcc/combine.c:14856
0x1675334 execute
/repo/gcc-trunk/gcc/combine.c:14901
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-256801-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-256801-checking-yes-rtl-df-extra-amd64
Thread model: posix
gcc version 8.0.1 20180117 (experimental) (GCC)

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #5 from Wilco  ---
Note there are other optimizations which can block a tailcall, for example:

void *f (void *p) { return __builtin_strchr (p, 0); }

f:
stp x19, x30, [sp, -16]!
mov x19, x0
bl  strlen
add x0, x19, x0
ldp x19, x30, [sp], 16
ret

f:
pushq   %rbx
movq%rdi, %rbx
callstrlen
addq%rbx, %rax
popq%rbx
ret


So the question is whether a tailcall is ever better than using a faster
library call.

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Wilco from comment #5)
> Note there are other optimizations which can block a tailcall, for example:
> 
> void *f (void *p) { return __builtin_strchr (p, 0); }

This is irrelevant since this refers to mempcpy only, nothing else.

[Bug c++/83931] New: Add support for -nostdlib++

[thomasanderson at google dot com]

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

Bug ID: 83931
   Summary: Add support for -nostdlib++
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomasanderson at google dot com
  Target Milestone: ---

Projects that want to link their own c++ standard library must currently pass
-nostdlib or -nodefaultlibs.  This means projects must add back -lm, -lc and so
on.  -nostdlib++ should be added (analogous to -nostdlib) for this use case.

LLVM added this feature in r308997 (https://reviews.llvm.org/rL308997), so gcc
should do the same.

[Bug c++/83931] Add support for -nostdlib++

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Use gcc for linking instead of g++ seems like the correct way.

[Bug c++/81167] [8 Regression] ICE on valid C++ code in deferred_printed_type, at cp/error.c:118

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
I think it is fine that %H/%I crash on bogus arguments, but we should fix here
the real bug.
+ if (! DECL_CONSTRUCTOR_P (w->fn)
+  && TREE_TYPE (source))
looks just like a workaround.  The main question is what is:
  tree source = source_type (w->convs[0]);
  if (! DECL_CONSTRUCTOR_P (w->fn))
source = TREE_TYPE (source);
code meant to do exactly, I bet it relies on the assumption that this argument
to w->fn must be a POINTER_TYPE_P, but in this case source is neither pointer
nor reference type, because source_type looked through the ck_ref_bind
conversion which had reference to bar type to the next conversion which is
ck_identity with bar type.  So, source already is a RECORD_TYPE rather than a
pointer/reference.

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[wilco at gcc dot gnu.org]

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

--- Comment #7 from Wilco  ---
(In reply to H.J. Lu from comment #6)
> (In reply to Wilco from comment #5)
> > Note there are other optimizations which can block a tailcall, for example:
> > 
> > void *f (void *p) { return __builtin_strchr (p, 0); }
> 
> This is irrelevant since this refers to mempcpy only, nothing else.

No it is relevant as strchr is used far more often than mempcpy. There are
likely other cases too. So if we want to add a mechanism to prefer tailcalls,
it would need to be a generic one rather than something hacked just for one
function.