[Bug fortran/84120] New: Syntax for used for PDT constructors is incorrect

[neil.n.carlson at gmail dot com]

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

Bug ID: 84120
   Summary: Syntax for used for PDT constructors is incorrect
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

Consider the PDT

type foo(dim)
  integer,len :: dim
  integer :: array(dim)
end type

While investigating how other compilers do on the gfortran testsuite programs,
I discovered that gfortran would use the following syntax for a constructor for
the PDT:

type(foo(2)) :: x
x = foo(2,[1,2])

This is absolutely wrong.  The correct constructor syntax is

x = foo(2)([1,2])

The PDT implementation appears to have the misconception that type parameters
are (in part) regular components, but that is not so, they are two separate
things. See PR84119 for some related references to the standard.  In particular
here, see R455 for the constructor syntax (F08 standard), and R453 for the
derived-type-spec (e.g. "foo(2)"). Note that 1.3.33 defines what a "component"
is, and it does not include type parameters.

To summarize, gfortran works with this invalid example (Intel and NAG properly
reject it)

type foo(dim)
  integer,len :: dim
  integer :: array(dim)
end type
type(foo(:)), allocatable :: x
x = foo(2,[1,2])
if (size(x%array) /= 2) stop 1
if (any(x%array /= [1,2])) stop 2
end

But gfortran rejects this corrected valid example (works with Intel and NAG):

type foo(dim)
  integer,len :: dim
  integer :: array(dim)
end type
type(foo(:)), allocatable :: x
x = foo(2)([1,2])
if (size(x%array) /= 2) stop 1
if (any(x%array /= [1,2])) stop 2
end

 x = foo(2)([1,2])
 1
Error: Invalid character in name at (1)

[Bug tree-optimization/65968] Failure to remove casts, cause poor code generation

[lesliezhai at llvm dot org.cn]

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

Leslie Zhai  changed:

   What|Removed |Added

 CC||lesliezhai at llvm dot org.cn

--- Comment #2 from Leslie Zhai  ---
not generated poor code for Mips target:


.file   1 "t.c"
.section .mdebug.abi64
.previous
.nanlegacy
.module fp=64
.module oddspreg
.abicalls
.text
.align  2
.align  3
.globl  f
.setnomips16
.setnomicromips
.entf
.type   f, @function
f:
.frame  $sp,0,$31   # vars= 0, regs= 0/0, args= 0, gp= 0
.mask   0x,0
.fmask  0x,0
.setnoreorder
.setnomacro
li  $3,8388608  # 0x80
daddu   $3,$4,$3
.align  3
.L2:
lh  $2,0($4)
daddiu  $4,$4,2
mul $2,$2,$2
bne $3,$4,.L2
sh  $2,-2($4)

j   $31
nop

.setmacro
.setreorder
.endf
.size   f, .-f
.ident  "GCC: (GNU) 5.5.0 20171010 (LLVM China GCC 5.5-2018.01)"

[Bug fortran/84119] New: Type parameter inquiry for PDT returns array instead of scalar

[neil.n.carlson at gmail dot com]

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

Bug ID: 84119
   Summary: Type parameter inquiry for PDT returns array instead
of scalar
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

There seems to be a misconception in the implementation of PDT that the type
parameters are (in part) just regular components of the type, so that for

type foo(a)
  integer, len :: a
end type
type(foo(a)) :: array(9)

the type inquiry array%a should give a rank-1 array of size 9. This is
incorrect. Type parameters are not components of the type. The F08 standard
clearly distinguishes between type parameter definition statements and
component definition statements. See R425, R431, R435, and in particular see
Note 6.7 which says "It [array%a, for example] is scalar even if designator is
an array."

Here's a test case that should pass.  GFortran will bail on both stop lines.

type :: vector(dim,kind)
  integer, len :: dim
  integer, kind :: kind
end type
type(vector(3,1)) :: a(10)
if (size(shape(a%dim)) /= 0) stop 1
if (size(shape(a%kind)) /= 0) stop 2
end

[Bug target/83828] FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c execution test

[kyukhin at gcc dot gnu.org]

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

--- Comment #7 from Kirill Yukhin  ---
On the other hand, if masked variant of vpopcnt[w,q] is being issued: there's
no way for reload to put 32/64 bit mask into mask register, since kmov[d,q] are
only available  under -mavx512bw switch.

We can insist user to issue -mavx512bw along w/ -mavx512bitalg if she is going
to use masked variants of corresponding intrinsics. Then only tests need to be
fixed.

[Bug target/82666] [7/8 regression]: sum += (x>128 ? x : 0) puts the cmov on the critical path (at -O2)

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
Aldy,

It's less about whether or not there is a cmov (I get one with and without
PRE), but more about what part of the loop we're using the cmov for.

Consider what we get in the .optimized dump at -O3 correct.  But the target
*assembly* we want is what you'd get with -O3 -fno-tree-pre.  ie, PRE is making
it harder for us to generate the cmov we want.

[Bug target/83828] FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c execution test

[kyukhin at gcc dot gnu.org]

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

Kirill Yukhin  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||kyukhin at gcc dot gnu.org

--- Comment #6 from Kirill Yukhin  ---
Looks like avx512bw demand is excessive in avx512bitalgintrin.h

[Bug testsuite/81010] [8 regression] test case gcc.target/powerpc/pr56605.c fails starting with r248958

[law at gcc dot gnu.org]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
  Component|tree-optimization   |testsuite

--- Comment #6 from Jeffrey A. Law  ---
Author: law
Date: Tue Jan 30 05:30:40 2018
New Revision: 257172

URL: https://gcc.gnu.org/viewcvs?rev=257172=gcc=rev
Log:
PR testsuite/81010
* gcc.target/powerpc/pr56605.c: Update various dg- directives to
better match other tests which require vsx.  Verify the zero
extension is part of the test in the combiner dump.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr56605.c

[Bug testsuite/81010] [8 regression] test case gcc.target/powerpc/pr56605.c fails starting with r248958

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org

--- Comment #6 from Aldy Hernandez  ---
Started with r243866.

commit 11082703aaa77f9d9587937d006a572cd7a1066a
Author: pthaugen 
Date:   Wed Dec 21 19:15:32 2016 +

PR rtl-optimization/11488
* common/config/rs6000/rs6000-common.c
(rs6000_option_optimization_table): Enable -fsched-pressure.
* config/rs6000/rs6000.c (TARGET_COMPUTE_PRESSURE_CLASSES): Define
target hook.
(rs6000_option_override_internal): Set default -fsched-pressure
algorithm.
(rs6000_compute_pressure_classes): Implement target hook.

[Bug rtl-optimization/83147] LRA inheritance undo on multiple sets problem

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #5 from Jeffrey A. Law  ---
Fixed by Vlad's patch on the trunk.

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

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #19 from Jeffrey A. Law  ---
Fixed by Bin's change on the trunk.

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|REOPENED|NEW

--- Comment #5 from Aldy Hernandez  ---
Ok, cpu makes a difference.  Thanks.

Confirmed with a cross to --target=powerpc-linux-gnu and:

./cc1 ~/a.c -quiet -O2 -fmodulo-sched -fselective-scheduling2 -I./ -mcpu=power7

Plus the following to make up for the missing assembler:

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 145ac86..0a8fa6a 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c   
@@ -4132,6 +4132,7 @@ rs6000_option_override_internal (bool global_init_p)
default:
  break;
}
+  unavailable_cpu=0;
   if (unavailable_cpu)
{
  cpu_index = -1;

[Bug rtl-optimization/84068] [8 Regression] ICE: qsort checking failed: qsort comparator non-negative on sorted output: 1 with -fno-sched-critical-path-heuristic --param=max-sched-extend-regions-iters

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com,
   ||wilco at gcc dot gnu.org

--- Comment #2 from Aldy Hernandez  ---
This may be a latent bug when the scheduling pressure model was changed, but
FWIW, this started with r254378.

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #4 from Arseny Solokha  ---
gcc/sel-sched.c:7150 in r255766 became sel-sched.c:7155 in 257131, which is

7149if (sched_verbose >= 2)
7150  {
7151sel_print ("scheduled insn %d, clock %d\n", INSN_UID (insn),
7152   haifa_clock + 1);
7153debug_state (curr_state);
7154  }
7155gcc_assert (cost < 0);
7156  }
7157
7158  if (targetm.sched.variable_issue)
7159targetm.sched.variable_issue (sched_dump, sched_verbose, insn, 0);

(In reply to Aldy Hernandez from comment #3)
> I tried again with latest trunk but still can't reproduce.  I even tried on
> a native PPC big endian box running in 32 bit mode (setarch).

% for cpu in 401 403 405 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603
603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5
a2 cell e300c2 e300c3 e500mc e500mc64 e5500 e6500 ec603e power3 power4 power5
power5+ power6 power6x power7 power8 power9 powerpc powerpc64 powerpc64le rs64
titan; do powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180128 -mcpu=$cpu -O2
-fmodulo-sched -fselective-scheduling2 -c tt.c || echo $cpu; done
during RTL pass: sched2
tt.c: In function 'ny':
tt.c:13:1: internal compiler error: in reset_sched_cycles_in_current_ebb, at
sel-sched.c:7155
 }
 ^
0xc08418 reset_sched_cycles_in_current_ebb
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sel-sched.c:7155
0xc08418 sel_region_target_finish
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sel-sched.c:7228
0xc08418 sel_region_finish
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sel-sched.c:7284
0xc08418 sel_sched_region(int)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sel-sched.c:7647
0xc08641 run_selective_scheduling()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sel-sched.c:7718
0xbdf4bd rest_of_handle_sched2
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sched-rgn.c:3729
0xbdf4bd execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sched-rgn.c:3873
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
zsh: exit 1 powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180128 -mcpu=$cpu -O2
-fmodulo-sche
power7

So apparently the processor-specific scheduling parameters play a role here.

(In reply to Aldy Hernandez from comment #3)
> Reporter also
> filed PR84090, which also can't be reproduced by at least two people.

I wonder what exactly this is supposed to mean. The ICE reported in PR84090 had
indeed gone between r256935 and r257131 and that would be sorted out by me
later this week anyway.

[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #9 from Jerry DeLisle  ---
OK, will see what I can do.

[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
Attached.

[Bug rtl-optimization/84068] [8 Regression] ICE: qsort checking failed: qsort comparator non-negative on sorted output: 1 with -fno-sched-critical-path-heuristic --param=max-sched-extend-regions-iters

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #1 from Aldy Hernandez  ---
Confirmed.

[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-30
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Aldy Hernandez  ---
Would you mind attaching a preprocessed testcase so this can be reproduced with
a cross compiler?  The failing testcase includes , and I don't have
hpux headers :).

[Bug lto/84105] [8 regression] Segmentation fault in pp_tree_identifier() during LTO

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

  Attachment #43282|0   |1
is obsolete||

--- Comment #6 from Aldy Hernandez  ---
Created attachment 43283
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43283=edit
untested patch

Actual untested patch :).

[Bug lto/84105] [8 regression] Segmentation fault in pp_tree_identifier() during LTO

[aldyh at gcc dot gnu.org]

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

--- Comment #5 from Aldy Hernandez  ---
Created attachment 43282
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43282=edit
untested patch

Proposed patch in testing.

[Bug lto/84105] [8 regression] Segmentation fault in pp_tree_identifier() during LTO

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #4 from Aldy Hernandez  ---
Started with r256685.

The problem is in dump_generic_node:

case FUNCTION_TYPE:
case METHOD_TYPE:
...
  if (TYPE_NAME (node) && DECL_NAME (TYPE_NAME (node)))
dump_decl_name (pp, TYPE_NAME (node), flags);

(gdb) print node
$21 = 
(gdb) print node.type_common.name
$22 = 

TYPE_NAME is an IDENTIFIER_NODE, whereas we're expecting a DECL_P, and we ICE.

[Bug libstdc++/84118] New: filesystem::path concat does not accept value_type

[ethan at ethanhs dot me]

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

Bug ID: 84118
   Summary: filesystem::path concat does not accept value_type
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ethan at ethanhs dot me
  Target Milestone: ---

As I have read the filesystem TS, I believe concat on path items should have an
overload following:

path& operator+=(value_type x);

However, on trying to use 7.2.0 this overload seems not to work correctly.

https://wandbox.org/permlink/S4DZ3witD15xz0lT

TL;DR it would allow for constructs such as
.concat(fs::path::preferred_separator)

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[msebor at gcc dot gnu.org]

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

--- Comment #14 from Martin Sebor  ---
Yes, the attribute affects all callers in the same translation unit and so it
needs to match across both the declarations and the definition.

I (and others) tested Glibc with this patch and if this had been an idiom there
I would have seen it or heard about it.  AFAIK, Glibc uses private symbols for
internal calls and those are aliases for the external symbols.  An alias can be
declared with one attribute even though its target is declared with another,
and GCC silently accepts it.  This, however, is a potential bug that Joseph
requested a warning for in pr81824.  I promised I'd work on it after I was done
with pr81544 but didn't get to it.

You seem to be making the argument that this warning is valuable only if it
points out bona fide bugs and that it is unacceptable when it, even in rare
instances, is issued for strictly safe/correct code, no matter how contrived or
esoteric the instances are and even if the code is questionable.

That's not a realistic expectation to have.  For every warning that points out
a meaningless or ambiguous construct there will always be examples where the
construct is safe.  If we held all warnings to this standard then we'd have to
cut the number of warnings GCC issues in half.  Have you ever did an analysis
of the rate of true vs false positives for -Wimplicit-fallthrough for instance?
 Or -Wignored-qualifiers, or -Wmissing-braces, or -Wparentheses, etc.  For all
of these one can come up with a more or less of an unusual use case that's not
strictly incorrect but that GCC warns for regardless.  In the cases of all
these warning options we've accepted that the gains of the true positives
outweigh the costs of false positives.  And in some cases, the costs have been
quite considerable.

But the fact aside that this report is not an example of a false positive due
to the use case you've contrived, I've seen no evidence that there are any
cases like it in the wild at all.  Even if there were some there aren't enough
of them to be a concern since no bugs have been filed.  If such examples come
to light I'll certainly do my best to deal with them.  But until then, I'd
prefer to focus on fixing real bugs that have been reported for existing code
to debating hypothetical problems.

[Bug lto/84105] [8 regression] Segmentation fault in pp_tree_identifier() during LTO

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #3 from Aldy Hernandez  ---
Confirmed with last step of:

gcc -fdump-ipa-inline-details   -m32 -o sctp.ko lto-test.o -rdynamic

(-rdynamic instead of -r).

[Bug c++/83937] [7/8 Regression] C++17 binds braced init of a type T to default arg of a ctor instead of using T's own default ctor

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Actually this might be just a missing TARGET_EXPR_DIRECT_INIT_P check in
build_special_member_call:

--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8824,7 +8824,8 @@ build_special_member_call (tree instance, tree name,
vec **args,
arg = perform_implicit_conversion_flags (class_type, arg,
 sub_complain,
 flags);
-  if ((TREE_CODE (arg) == TARGET_EXPR
+  if (((TREE_CODE (arg) == TARGET_EXPR
+   && TARGET_EXPR_DIRECT_INIT_P (arg))
   || TREE_CODE (arg) == CONSTRUCTOR)
  && (same_type_ignoring_top_level_qualifiers_p
  (class_type, TREE_TYPE (arg

[Bug tree-optimization/84111] [8 Regression] Compile time hog w/ -O2

[matz at gcc dot gnu.org]

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

--- Comment #7 from Michael Matz  ---
(In reply to Jakub Jelinek from comment #6)
> Sure, but some of the mentioned SSA_NAMEs are registered for update and SCEV
> code is called before that happens.

Yes, sure.  That still doesn't necessarily mean that they have to be generally
aware of this as long as the not-yet-updated SSA form is "reasonably"
reflecting
the original code.  An cycle in SSA name definition quite clearly is
not reasonable, so a better approach is to not generate that situation.

(It might of course be the case that we can't easily avoid creating that
situation, in that case we have to change follow_copies_to_constant()
or friends.  But I don't think we have established that yet).

[Bug libgomp/84096] Wrong prototype for omp_init_nest_lock_with_hint() in "omp.h.in"

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jan 29 23:38:01 2018
New Revision: 257167

URL: https://gcc.gnu.org/viewcvs?rev=257167=gcc=rev
Log:
PR libgomp/84096
* omp.h.in (omp_init_nest_lock_with_hint): Use omp_nest_lock_t
instead of omp_lock_t.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/omp.h.in

[Bug tree-optimization/84111] [8 Regression] Compile time hog w/ -O2

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Sure, but some of the mentioned SSA_NAMEs are registered for update and SCEV
code is called before that happens.

[Bug tree-optimization/84111] [8 Regression] Compile time hog w/ -O2

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |matz at gcc dot gnu.org

--- Comment #5 from Michael Matz  ---
(In reply to Jakub Jelinek from comment #3)
> Seems during cunroll we end up with:
> y_8 = PHI 
> ...
> y_29 = PHI 
> ...
> y_37 = PHI 
> 
> where all 3 PHIs are degenerate and thus:

This is invalid SSA form.  PHI operand definitions must dominate their use, but
the above forms a cycle.  Probably a result of unroll-jam not carefully dealing
with unreachable code after the infinite loops; but we shouldn't generate such
code.  Adding hacks to follow_copies_to_constant doesn't seem a good idea;
that one is supposed to be able to rely on correct SSA form.

I'll take a look.

[Bug c++/84091] [8 Regression] ICE on valid C++ code: Segmentation fault

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag

[yann.collet.73 at gmail dot com]

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

Yann Collet  changed:

   What|Removed |Added

 CC||yann.collet.73 at gmail dot com

--- Comment #14 from Yann Collet  ---
Is gcc -mbmi2 currently able to generate automatically a bzhi instruction when
it detects a "X & ((1 << Y) - 1)" sequence, as suggested by James Almer ?
If yes, are there some available examples ?

[Bug libstdc++/84087] string::assign problem with two arguments

[bseifert at gmx dot at]

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

Berni  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Berni  ---

thank you. I confirm, the patch is working properly.

hope this will go into gcc 8.0 release!? the current snapshot (some days ago)
does not seem to be fixed yet.

[Bug tree-optimization/84042] IVOPTS doesn't optimize int indexes on some PowerPC code starting with svn id 250482

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #1 from Michael Meissner  ---
This shows up if we allow PRE_{INC,DEC,MODIFY} of DFmode and SFmode values if
those values can go in Altivec registers.

To reproduce this, compile the following code with either -O2 -mcpu=power6 or
-O2 -mcpu=power7 -mno-vsx:

void f(double *a, double *b, double *c, int n) {
  int i;
  for (i=0; i < n; i++)
a[i] = b[i] + c[i];
}

The code generated is:

f:
cmpwi 7,6,0
blelr 7
addi 6,6,-1
addi 9,4,-8
rldic 6,6,3,29
addi 5,5,-8
add 4,4,6
addi 3,3,-8
.p2align 4,,15
.L3:
lfdu 0,8(9)
lfdu 12,8(5)
cmpld 7,9,4
fadd 0,0,12
stfdu 0,8(3)
beqlr 7
lfdu 0,8(9)
lfdu 12,8(5)
cmpld 7,9,4
fadd 0,0,12
stfdu 0,8(3)
bne 7,.L3
blr

Subversion id 257166 disallowed PRE_{INC,DEC,MODIFY} for the floating point
scalars could go in Altivec registers and -O2 -mcpu=power7 generates:

f:
cmpwi 7,6,0
blelr 7
addi 6,6,-1
li 9,0
rldicl 6,6,0,32
addi 10,6,1
mtctr 10
.p2align 5,,31
.L3:
lfdx 0,4,9
lfdx 12,5,9
fadd 0,0,12
stfdx 0,3,9
addi 9,9,8
bdnz .L3
blr


Or alternatively compile the following code with -O2 -mcpu=power7:

void f(float *a, float *b, float *c, int n) {
  int i;
  for (i=0; i < n; i++)
a[i] = b[i] + c[i];
}

[Bug target/81550] [8 regression] gcc.target/powerpc/loop_align.c fails starting with r250482

[meissner at gcc dot gnu.org]

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

--- Comment #11 from Michael Meissner  ---
Author: meissner
Date: Mon Jan 29 22:30:34 2018
New Revision: 257166

URL: https://gcc.gnu.org/viewcvs?rev=257166=gcc=rev
Log:
2018-01-29  Michael Meissner  

PR target/81550
* config/rs6000/rs6000.c (rs6000_setup_reg_addr_masks): If DFmode
and SFmode can go in Altivec registers (-mcpu=power7 for DFmode,
-mcpu=power8 for SFmode) don't set the PRE_INCDEC or PRE_MODIFY
flags.  This restores the settings used before the 2017-07-24.
Turning off pre increment/decrement/modify allows IVOPTS to
optimize DF/SF loops where the index is an int.


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

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #12)
> AFAIK, specifying attribute const and pure on a function definition has no
> effect on the code emitted for the function itself or on its callers in
> other translation units, so what you describe doesn't sound meaningful.

The attribute on function definition affects all code in that TU.
Or, look at e.g. glibc external vs. internal headers, external headers are
something that is for users outside of glibc, internal headers include the
external ones and can tweak stuff for the internal users.  External header
could use pure attribute, internal could use const attribute (or just one
internal header for a particular sysdep etc.).  Many other projects use similar
header schemes.

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Aldy Hernandez  ---
I tried again with latest trunk but still can't reproduce.  I even tried on a
native PPC big endian box running in 32 bit mode (setarch).  Reporter also
filed PR84090, which also can't be reproduced by at least two people.

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[msebor at gcc dot gnu.org]

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

--- Comment #12 from Martin Sebor  ---
AFAIK, specifying attribute const and pure on a function definition has no
effect on the code emitted for the function itself or on its callers in other
translation units, so what you describe doesn't sound meaningful.

It's fine, though pointless, to declare a function pure and define it so that
it meets stricter requirements under some conditions, just as long as the
attributes don't clash.

[Bug fortran/84109] ICE in adjustl on allocatable array of strings

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
The ICE vanishes with -fno-realloc-lhs.

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[acsawdey at gcc dot gnu.org]

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

--- Comment #31 from acsawdey at gcc dot gnu.org ---
I'm not sure where the copy happens, I am just surmising that it must have been
added because the code clearly assumes it won't be copied.

[Bug c++/84098] [8 Regression] ICE when using a lambda in a in-class static member initialization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[rsandifo at gcc dot gnu.org]

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

--- Comment #30 from rsandifo at gcc dot gnu.org  
---
(In reply to acsawdey from comment #29)
> The problematic expression was:
> 
> (mem/c:QI (plus:DI (plus:DI (reg/f:DI 187) (const_int 32 [0x20])) (const_int
> 72 [0x48]))
> 
> and internal_arg_pointer was (plus:DI (reg/f:DI 187) (const_int 32 [0x20]))
> ... just not the same rtx object in both places.

Where does it get copied?

> It seems like the +32 is FIRST_PARM_OFFSET for ppc64le. 187 is in fact just
> a copy of the stack pointer (r12).
> 
> It seems like there is something that decomposed the whole offset of 104,
> which is seen elsewhere after expand into 32+72.
> 
> If I understand correctly, you are saying that if the rtx with splitstack on
> was just reg+104, we would not recognize that because we are looking for
> this particular reg+32 pattern?

Yeah.  I'm not sure how we end up with the nested pluses
(which would normally be folded into one) but don't end up with
equal addresses for the inner plus.  It seems like a weird half
measure.

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
There is a valid use case, you have some public interface which you only want
to guarantee to be pure, the result depends on the arguments and e.g. on some
OSes or in some specific cases needs read-only access to global variables.
So you add __attribute__((pure)) to the public header for the function, that is
what you guarantee to outside users.
Then, for a specific configuration/OS/specific case you actually don't need the
access to global variables, so e.g. within the library or just with the TU with
the definition or something similar you make the guarantee stronger and use
__attribute__((const)).  Uses that see just the pure attribute optimize based
on that attribute, uses that see the const attribute or both optimize further.

[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures

[anlauf at gmx dot de]

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

--- Comment #8 from Harald Anlauf  ---
(In reply to jsberg from comment #7)
> As to why I think this is a bug (and why I think Intel's compiler is doing
> the right thing), referencing the 2008 standard (N1830):

In the F2018 DIS (N2146) the corresponding section is 13.11.  It appears
to have been heavily reorganized, but AFAICT from a first glance it is
quite similar.

E.g.

> 10.11.3.2, paragraph 2:
> 
> When the designator in the input record represents an array variable or a
> variable of derived type, the effect is as if the variable represented were
> expanded into a sequence of scalar list items, in the same way that formatted
> input/output list items are expanded (9.6.3).

is now 13.11.3.2, paragraph 2.

> 10.11.3.3, paragraph 1:
> 
> ... The r*c form is equivalent to r successive appearances of the constant c

There's some change in wording here in 13.11.3.3, paragraph 1, explaining
the r* form for multiple null values.

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[arnd at linaro dot org]

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

--- Comment #5 from Arnd Bergmann  ---
Here are some additional instances in the kernel. I'm currently trying to get a
reliable build first and haven't got a log of all the messages, but there are a
number of changes I did that are related, shutting up the -Wrestrict warning
(some may be -Warray-bounds).

Here are some false-positives:

--- a/arch/x86/oprofile/nmi_int.c
+++ b/arch/x86/oprofile/nmi_int.c
@@ -282,9 +282,7 @@ static void mux_clone(int cpu)
if (!has_mux())
return;

-   memcpy(per_cpu(cpu_msrs, cpu).multiplex,
-  per_cpu(cpu_msrs, 0).multiplex,
-  sizeof(struct op_msr) * model->num_virt_counters);
+   per_cpu(cpu_msrs, cpu).multiplex = per_cpu(cpu_msrs, 0).multiplex;
 }

 #else
@@ -463,6 +461,7 @@ static int nmi_setup(void)
if (!cpu)
continue;

+#ifdef CONFIG_SMP
memcpy(per_cpu(cpu_msrs, cpu).counters,
   per_cpu(cpu_msrs, 0).counters,
   sizeof(struct op_msr) * model->num_counters);
@@ -470,7 +469,7 @@ static int nmi_setup(void)
memcpy(per_cpu(cpu_msrs, cpu).controls,
   per_cpu(cpu_msrs, 0).controls,
   sizeof(struct op_msr) * model->num_controls);
-
+#endif
mux_clone(cpu);
}
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -1643,7 +1643,7 @@ static int cfg80211_rtw_scan(struct wiphy *wiphy
spin_lock_bh(>lock);
if (request->n_channels == 1) {
for (i = 1;in_channels <= 4) {
for (j =request->n_channels-1;j>= 0;j--)


This one was weird, I suspect my change is incorrect:

diff --git a/drivers/fmc/fmc-fakedev.c b/drivers/fmc/fmc-fakedev.c
index 941d0930969a..0d322380d952 100644
--- a/drivers/fmc/fmc-fakedev.c
+++ b/drivers/fmc/fmc-fakedev.c
@@ -305,7 +305,7 @@ static int ff_init(void)

/* Replicate the default eeprom for the max number of mezzanines */
for (i = 1; i < FF_MAX_MEZZANINES; i++)
-   memcpy(ff_eeimg[i], ff_eeimg[0], sizeof(ff_eeimg[0]));
+   memcpy(_eeimg[i][0], _eeimg[0][0], sizeof(ff_eeimg[0]));

if (ff_nr_eeprom > ff_nr_dev)
ff_nr_dev = ff_nr_eeprom;

This one seems to be a kernel bug:

--- a/kernel/debug/kdb/kdb_support.c
+++ b/kernel/debug/kdb/kdb_support.c
@@ -129,13 +129,13 @@ int kdbnearsym(unsigned long addr, kdb_symtab_t *symtab)
}
if (i >= ARRAY_SIZE(kdb_name_table)) {
debug_kfree(kdb_name_table[0]);
-   memcpy(kdb_name_table, kdb_name_table+1,
+   memmove(kdb_name_table, kdb_name_table+1,
   sizeof(kdb_name_table[0]) *
   (ARRAY_SIZE(kdb_name_table)-1));
} else {
debug_kfree(knt1);
knt1 = kdb_name_table[i];
-   memcpy(kdb_name_table+i, kdb_name_table+i+1,
+   memmove(kdb_name_table+i, kdb_name_table+i+1,
   sizeof(kdb_name_table[0]) *
   (ARRAY_SIZE(kdb_name_table)-i-1));
}

[Bug c++/83835] [7/8 Regression] constexpr constructor rejected in c++17 mode (regression WRT c++14)

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Perhaps we also want to set TARGET_EXPR_DIRECT_INIT_P here:

 6785 /* If this is a constructor or a function returning an aggr type,
 6786we need to build up a TARGET_EXPR.  */
 6787 if (DECL_CONSTRUCTOR_P (convfn))
 6788   {
 6789 expr = build_cplus_new (totype, expr, complain);
 6790 
 6791 /* Remember that this was list-initialization.  */
 6792 if (convs->check_narrowing && expr != error_mark_node)
 6793   TARGET_EXPR_LIST_INIT_P (expr) = true;
 6794   }

[Bug c++/82461] [7 Regression] Temporary required for brace-initializing (non-literal-type) member variable

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for 7.4 as well.

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

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

   Target Milestone|8.0 |7.4

--- Comment #25 from Joseph S. Myers  ---
Also now fixed for GCC 7.4.

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

[jsm28 at gcc dot gnu.org]

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

--- Comment #24 from Joseph S. Myers  ---
Author: jsm28
Date: Mon Jan 29 21:00:52 2018
New Revision: 257165

URL: https://gcc.gnu.org/viewcvs?rev=257165=gcc=rev
Log:
Fix m68k-linux-gnu libgcc build for ColdFire (PR target/68467).

PR target/68467 is libgcc failing to build for m68k-linux-gnu
configured for ColdFire.

Jeff has an analysis in the PR identifying the problem as resulting
from the callers of libcalls with 1-byte or 2-byte arguments wanting
to push just 1 or 2 bytes on the stack, while the libcall
implementations have the normal C ABI and expect 4-byte arguments.
For normal C functions, I believe the TARGET_PROMOTE_PROTOTYPES
definition would ensure such arguments get passed as 4-byte, but that
does not apply for libcalls.

This patch fixes the issue by defining TARGET_PROMOTE_FUNCTION_MODE
for m68k.  The definition is conservative, only applying promotions in
the case of arguments to libcalls; otherwise it returns the unpromoted
type, which I believe matches what the default implementation of the
hook would have done on m68k.

I have tested that this fixes the libgcc build for ColdFire, and, in
conjunction with one glibc patch, this enables glibc to build cleanly
for ColdFire and to pass the compilation parts of the glibc testsuite
except for one test unrelated to this patch (while glibc and the
compilation parts of the testsuite continue to build OK for
non-ColdFire m68k, as expected).  I have *not* run any GCC tests for
this patch, or any execution tests for m68k.

Backport from mainline
2018-01-24  Joseph Myers  

PR target/68467
* config/m68k/m68k.c (m68k_promote_function_mode): New function.
(TARGET_PROMOTE_FUNCTION_MODE): New macro.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/m68k/m68k.c

[Bug c++/82461] [7 Regression] Temporary required for brace-initializing (non-literal-type) member variable

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Mon Jan 29 20:58:36 2018
New Revision: 257164

URL: https://gcc.gnu.org/viewcvs?rev=257164=gcc=rev
Log:
PR c++/82461 - constexpr list-initialized member

* constexpr.c (potential_constant_expression_1): Check
TARGET_EXPR_DIRECT_INIT_P.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-list2.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/constexpr.c

[Bug c++/83996] [6/7] Regression] ICE with zero-sized array

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[6/7/8] Regression] ICE |[6/7] Regression] ICE with
   |with zero-sized array   |zero-sized array

--- Comment #3 from Marek Polacek  ---
Fixed for 8 so far.

[Bug c++/68810] [8 regression] FAIL: g++.dg/cpp0x/constexpr-reinterpret1.C -- test for errors -- -m32

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #20 from Jason Merrill  ---
Fixed, though we're still folding too many things.

[Bug c++/68810] [8 regression] FAIL: g++.dg/cpp0x/constexpr-reinterpret1.C -- test for errors -- -m32

[jason at gcc dot gnu.org]

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

--- Comment #19 from Jason Merrill  ---
Author: jason
Date: Mon Jan 29 20:56:00 2018
New Revision: 257161

URL: https://gcc.gnu.org/viewcvs?rev=257161=gcc=rev
Log:
PR c++/68810 - wrong location for reinterpret_cast error.

* cvt.c (cp_convert_to_pointer): Always build a CONVERT_EXPR when
!dofold.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-reinterpret1.C

[Bug c++/83996] [6/7/8] Regression] ICE with zero-sized array

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Mon Jan 29 20:54:12 2018
New Revision: 257160

URL: https://gcc.gnu.org/viewcvs?rev=257160=gcc=rev
Log:
PR c++/83996
* constexpr.c (cxx_fold_indirect_ref): Compute ((foo *))[1]
=> fooarray[1] in offset_int.

* g++.dg/ext/pr83996.C: New test.

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

[Bug lto/84105] [8 regression] Segmentation fault in pp_tree_identifier() during LTO

[arnd at linaro dot org]

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

--- Comment #2 from Arnd Bergmann  ---
Created attachment 43281
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43281=edit
preprocessed simplified sm_sideeffect.c, compressed

I managed to get a standalone testcase now, manually reduced the original
source and then preprocessed. Further automated reduction should be easy now if
necessary.

x86_64-linux-gcc-8.0.1 -c -m32 -o lto-test.o lto-test.i -O2 -flto
-Wno-pointer-sign -fno-strict-aliasing
x86_64-linux-gcc-8.0.1  -fdump-ipa-inline-details   -m32 -r-o sctp.ko
lto-test.o

The part that goes wrong is apparently the '-fdump-ipa-inline-details'.

/git/arm-soc/net/sctp/lto-test.c: In function 'sctp_do_sm':
/git/arm-soc/net/sctp/lto-test.c:120:5: internal compiler error: Segmentation
fault
 int sctp_do_sm(struct net *net, enum sctp_event event_type,
 ^
0xa42b7f crash_signal
/home/arnd/git/gcc/gcc/toplev.c:325
0xaf0659 pp_tree_identifier(pretty_printer*, tree_node*)
/home/arnd/git/gcc/gcc/tree-pretty-print.c:4006
0xaf0966 dump_decl_name
/home/arnd/git/gcc/gcc/tree-pretty-print.c:261
0xaf42ea dump_generic_node(pretty_printer*, tree_node*, int, unsigned long,
bool)
/home/arnd/git/gcc/gcc/tree-pretty-print.c:1826
0xaf769a print_declaration(pretty_printer*, tree_node*, int, unsigned long)
/home/arnd/git/gcc/gcc/tree-pretty-print.c:
0xaf7997 print_generic_decl(_IO_FILE*, tree_node*, unsigned long)
/home/arnd/git/gcc/gcc/tree-pretty-print.c:122
0xb4603a dump_scope_block
/home/arnd/git/gcc/gcc/tree-ssa-live.c:647
0xb471b9 dump_scope_blocks(_IO_FILE*, unsigned long)
/home/arnd/git/gcc/gcc/tree-ssa-live.c:678
0xb471b9 remove_unused_locals()
/home/arnd/git/gcc/gcc/tree-ssa-live.c:870
0x97af44 execute_function_todo
/home/arnd/git/gcc/gcc/passes.c:1972
0x97b8b9 execute_todo
/home/arnd/git/gcc/gcc/passes.c:2048
0x97dac5 execute_one_ipa_transform_pass
/home/arnd/git/gcc/gcc/passes.c:2245
0x97dac5 execute_all_ipa_transforms()
/home/arnd/git/gcc/gcc/passes.c:2281
0x6d681c cgraph_node::expand()
/home/arnd/git/gcc/gcc/cgraphunit.c:2132
0x6d7b38 expand_all_functions
/home/arnd/git/gcc/gcc/cgraphunit.c:2275
0x6d7b38 symbol_table::compile()
/home/arnd/git/gcc/gcc/cgraphunit.c:2624
0x656c51 lto_main()
/home/arnd/git/gcc/gcc/lto/lto.c:3349
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /home/arnd/cross-gcc/bin/x86_64-linux-gcc-8.0.1
returned 1 exit status
compilation terminated.
/home/arnd/cross-gcc/lib/gcc/x86_64-linux/8.0.1/../../../../x86_64-linux/bin/ld:
error: lto-wrapper failed

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #9)

This is not a style warning.  Because there is no valid use case for having
both attribute const and pure on two declarations of the same function, in the
absence of access to its definition there also is no one correct choice to make
as to which one to honor and which one to ignore.  Honoring const when the
definition is, in fact, pure, is a bug.  Honoring pure when the definition is
const results in less than optimal code.

In cases where there is no one correct/safe/optimal choice the best response is
to point out the conflict/ambiguity and let the user resolve it based on the
definition of the function.

The difference the patch introduces is that rather than always honoring const
as before, GCC 8 honors the attribute on the first declaration.  (My preference
would have been to honor pure to be on the safe side but I didn't think there
would have been sufficient support for the change and, with a warning, it also
didn't seem like as big a risk anymore, while a consistent treatment of all
conflicts seems like a more important goal).

But this bug is not the right place to discuss the merits of the warning itself
or the handling of conflicts.

[Bug target/84066] Wrong shadow stack register size is saved for x32

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
(In reply to igor.v.tsimbalist from comment #6)

> > 
> > reg_ssp must be in word_mode, not in Pmode.
> 
> reg_ssp is word_mode. It's reg_adj that is Pmode (it's increment to shadow
> stack).

OK.

> > Please show the assembly outputs of __builtin_setjmp and __builtin_longjmp
> > with the updated patch.
> 
> A snippet for __builtin_longjmp for -mx32
> 
> movl$0, %eax

Please use xor.

> rdsspq  %rax
> subqbuf+12(%rip), %rax
> je  .L2
> negl%eax
> shrl$2, %eax
^ Shouldn't be "shrl $3, %eax" since SSP is 64-bit?

> cmpl$255, %eax
> jbe .L3
> .L4:
> incsspq %rax
> subl$255, %eax
> cmpl$255, %eax
> ja  .L4
> .L3:
> incsspq %rax
> .L2:
> 
> Snippet for __builtin_setjmp for -mx32
> 
> movl%eax, buf(%rip)
> movl$.L8, buf+4(%rip)
> movl%esp, buf+8(%rip)
> movl$0, %eax

xor.

> rdsspq  %rax
> movq%rax, buf+12(%rip)

[Bug c++/68810] [8 regression] FAIL: g++.dg/cpp0x/constexpr-reinterpret1.C -- test for errors -- -m32

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/84066] Wrong shadow stack register size is saved for x32

[igor.v.tsimbalist at intel dot com]

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

--- Comment #6 from igor.v.tsimbalist at intel dot com ---
(In reply to H.J. Lu from comment #5)
> (In reply to igor.v.tsimbalist from comment #4)
> > Created attachment 43280 [details]
> > updated patch
> 
> -  mem = gen_rtx_MEM (Pmode, plus_constant (Pmode, operands[0],
> -3 * GET_MODE_SIZE (Pmode)));
> -  reg_ssp = gen_reg_rtx (Pmode);
> +  mem = gen_rtx_MEM (word_mode, plus_constant (Pmode, operands[0],
> +   3 * GET_MODE_SIZE (Pmode)));
> 
> The first 3 fields are SP, FP and IP, which are in ptr_mode, not Pmode.

ok.

>/* Compute the numebr of frames to adjust.  */
> +  reg_adj = gen_rtx_SUBREG (Pmode, reg_ssp, 0);
> 
> reg_ssp must be in word_mode, not in Pmode.

reg_ssp is word_mode. It's reg_adj that is Pmode (it's increment to shadow
stack).

> Please show the assembly outputs of __builtin_setjmp and __builtin_longjmp
> with the updated patch.

A snippet for __builtin_longjmp for -mx32

movl$0, %eax
rdsspq  %rax
subqbuf+12(%rip), %rax
je  .L2
negl%eax
shrl$2, %eax
cmpl$255, %eax
jbe .L3
.L4:
incsspq %rax
subl$255, %eax
cmpl$255, %eax
ja  .L4
.L3:
incsspq %rax
.L2:

Snippet for __builtin_setjmp for -mx32

movl%eax, buf(%rip)
movl$.L8, buf+4(%rip)
movl%esp, buf+8(%rip)
movl$0, %eax
rdsspq  %rax
movq%rax, buf+12(%rip)

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Thanks.

Just for reference in case more of these should pop up, I see two -Wrestrict
instances in my build (below).  The first one looks correct but the second one
could be an instance of the false positive reported here.  If you come across
others please open new bugs (it would be helpful if I could reproduce your
build so if you can share your config file and/or whatever else I might need
that would be great).

net/mac80211/cfg.c:2794:3: warning: ‘memcpy’ source argument is the same as
destination [-Wrestrict]
   memcpy(pos, beacon->probe_resp, beacon->probe_resp_len);

drivers/iommu/amd_iommu.c: In function ‘get_alias’:
drivers/iommu/amd_iommu.c:310:4: warning: ‘memcpy’ accessing 32 bytes at
offsets 0 and 0 overlaps 32 bytes at offset 0 [-Wrestrict]
memcpy(amd_iommu_dev_table[pci_alias].data,
^~~
   amd_iommu_dev_table[devid].data,
   
   sizeof(amd_iommu_dev_table[pci_alias].data));
   

PS The breakdown of all warnings I see is below (the Unique column gives the
number of distinct origins of the warning, and the Files column the number of
distinct originating files):

DiagnosticCount   UniqueFiles
-Wattributes   213911
-Wattribute-alias   46533
-Wpacked-not-aligned 45   173
-Wstringop-truncation39   23   10
-Wformat-truncation= 21   21   15
-Wint-in-bool-context10   102
-Wformat-overflow=332
-Wstringop-overflow=  222
-Wrestrict222
-Warray-bounds222
-Wsizeof-pointer-memaccess111
-Wnonnull 111

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
If you mean it as a coding style warning (at least for const/pure), then it is
at least worded incorrectly, there is no conflict between those and if what you
do is that you ignore const attribute because earlier decl had pure attribute,
then regardless of -w/-Wattributes/-Wno-attributes etc. you've undesirably
changed behavior of something that was well defined before.

[Bug c++/4131] The C++ compiler doesn't place a const class object to ".rodata" section with non trivial constructor

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||antoshkka at gmail dot com

--- Comment #31 from Andrew Pinski  ---
*** Bug 84103 has been marked as a duplicate of this bug. ***

[Bug c++/84103] Dynamic initialization is performed for non-local variables in case when constant initialization is permitted

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 4131.

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

[Bug c++/24928] static const objects should go to .rodata

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||antoshkka at gmail dot com

--- Comment #4 from Andrew Pinski  ---
*** Bug 84099 has been marked as a duplicate of this bug. ***

[Bug c++/84099] Dynamic initialization is performed for static local variables in case when constant initialization is permitted

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
dup of bug 24928.

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

[Bug lto/84105] [8 regression] Segmentation fault in pp_tree_identifier() during LTO

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |8.0

--- Comment #1 from Andrew Pinski  ---
Can you try to reduce a testcase?

[Bug target/84066] Wrong shadow stack register size is saved for x32

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to igor.v.tsimbalist from comment #4)
> Created attachment 43280 [details]
> updated patch

-  mem = gen_rtx_MEM (Pmode, plus_constant (Pmode, operands[0],
-  3 * GET_MODE_SIZE (Pmode)));
-  reg_ssp = gen_reg_rtx (Pmode);
+  mem = gen_rtx_MEM (word_mode, plus_constant (Pmode, operands[0],
+ 3 * GET_MODE_SIZE (Pmode)));

The first 3 fields are SP, FP and IP, which are in ptr_mode, not Pmode.

   /* Compute the numebr of frames to adjust.  */
+  reg_adj = gen_rtx_SUBREG (Pmode, reg_ssp, 0);

reg_ssp must be in word_mode, not in Pmode.

Please show the assembly outputs of __builtin_setjmp and __builtin_longjmp
with the updated patch.

[Bug target/84066] Wrong shadow stack register size is saved for x32

[igor.v.tsimbalist at intel dot com]

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

--- Comment #4 from igor.v.tsimbalist at intel dot com ---
Created attachment 43280
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43280=edit
updated patch

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[acsawdey at gcc dot gnu.org]

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

--- Comment #29 from acsawdey at gcc dot gnu.org ---
The problematic expression was:

(mem/c:QI (plus:DI (plus:DI (reg/f:DI 187) (const_int 32 [0x20])) (const_int 72
[0x48]))

and internal_arg_pointer was (plus:DI (reg/f:DI 187) (const_int 32 [0x20])) ...
just not the same rtx object in both places.

It seems like the +32 is FIRST_PARM_OFFSET for ppc64le. 187 is in fact just a
copy of the stack pointer (r12).

It seems like there is something that decomposed the whole offset of 104, which
is seen elsewhere after expand into 32+72.

If I understand correctly, you are saying that if the rtx with splitstack on
was just reg+104, we would not recognize that because we are looking for this
particular reg+32 pattern?

[Bug tree-optimization/84111] [8 Regression] Compile time hog w/ -O2

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Seems this is during
#0  follow_copies_to_constant (var=) at
../../gcc/tree-scalar-evolution.c:1548
#1  0x010ce55e in analyze_scalar_evolution_1 (loop=0x7fffefb99550,
var=)
at ../../gcc/tree-scalar-evolution.c:2036
#2  0x010ce7ff in analyze_scalar_evolution (loop=0x7fffefb99550,
var=) at ../../gcc/tree-scalar-evolution.c:2114
#3  0x010ce8be in analyze_scalar_evolution_in_loop
(wrto_loop=0x7fffefb99550, use_loop=0x7fffefb99550, version=, 
folded_casts=0x7fffd6bf) at ../../gcc/tree-scalar-evolution.c:2210
#4  0x010d151e in simple_iv_with_niters (wrto_loop=0x7fffefb99550,
use_loop=0x7fffefb99550, op=, 
iv=0x7fffd7f0, iv_niters=0x7fffd7c8, allow_nonconstant_step=false)
at ../../gcc/tree-scalar-evolution.c:3326
#5  0x01183ef6 in number_of_iterations_exit_assumptions
(loop=0x7fffefb99550, exit= 10)>, 
niter=0x7fffd8d0, at_stmt=0x7fffd8a8, every_iteration=true) at
../../gcc/tree-ssa-loop-niter.c:2358
#6  0x0118437a in number_of_iterations_exit (loop=0x7fffefb99550,
exit= 10)>, niter=0x7fffd8d0, 
warn=false, every_iteration=true) at ../../gcc/tree-ssa-loop-niter.c:2442
#7  0x01184470 in find_loop_niter (loop=0x7fffefb99550,
exit=0x7fffda28) at ../../gcc/tree-ssa-loop-niter.c:2474
#8  0x011556fb in canonicalize_loop_induction_variables
(loop=0x7fffefb99550, create_iv=false, ul=UL_NO_GROWTH, try_eval=false, 
allow_peel=true) at ../../gcc/tree-ssa-loop-ivcanon.c:1198
#9  0x0115609d in tree_unroll_loops_completely_1
(may_increase_size=false, unroll_outer=true, father_bbs=0x2ac25e0,
loop=0x7fffefb99550)
at ../../gcc/tree-ssa-loop-ivcanon.c:1410
#10 0x01155faf in tree_unroll_loops_completely_1
(may_increase_size=false, unroll_outer=true, father_bbs=0x2ac25e0,
loop=0x7fffefb99000)
at ../../gcc/tree-ssa-loop-ivcanon.c:1379
#11 0x01156180 in tree_unroll_loops_completely
(may_increase_size=false, unroll_outer=true) at
../../gcc/tree-ssa-loop-ivcanon.c:1450

A few possible fixes:
1) just apply an upper bound on how many times we loop:
--- gcc/tree-scalar-evolution.c.jj  2018-01-03 10:19:54.735533890 +0100
+++ gcc/tree-scalar-evolution.c 2018-01-29 20:04:33.198563895 +0100
@@ -1540,9 +1540,12 @@ static tree
 follow_copies_to_constant (tree var)
 {
   tree res = var;
+  int depth = 0;
   while (TREE_CODE (res) == SSA_NAME)
 {
   gimple *def = SSA_NAME_DEF_STMT (res);
+  if (++depth == PARAM_VALUE (PARAM_MAX_SSA_NAME_QUERY_DEPTH))
+   break;
   if (gphi *phi = dyn_cast  (def))
{
  if (tree rhs = degenerate_phi_result (phi))
or give up if name_registered_for_update_p:
--- gcc/tree-scalar-evolution.c.jj  2018-01-03 10:19:54.735533890 +0100
+++ gcc/tree-scalar-evolution.c 2018-01-29 20:30:50.986363089 +0100
@@ -1540,7 +1540,8 @@ static tree
 follow_copies_to_constant (tree var)
 {
   tree res = var;
-  while (TREE_CODE (res) == SSA_NAME)
+  while (TREE_CODE (res) == SSA_NAME
+&& !name_registered_for_update_p (res))
 {
   gimple *def = SSA_NAME_DEF_STMT (res);
   if (gphi *phi = dyn_cast  (def))

or a combination of both.  Thoughts on this?

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[arnd at linaro dot org]

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

--- Comment #3 from Arnd Bergmann  ---
(In reply to Martin Sebor from comment #2)
> (In reply to Arnd Bergmann from comment #0)
> 
> Let me work on this.
> 
> I tested the warning with the kernel but don't recall coming across this
> false positive.  While I retry with the latest, how many of these do you see?

They are fairly rare, I have seen four or five now with randconfig builds over
the last two days. It's possible that there is none in the default config.

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
(In reply to Arnd Bergmann from comment #0)

Let me work on this.

I tested the warning with the kernel but don't recall coming across this false
positive.  While I retry with the latest, how many of these do you see?

[Bug fortran/84117] New: [8 Regression] ICE in gimplify_modify_expr, at gimplify.c:5798

[gs...@t-online.de]

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

Bug ID: 84117
   Summary: [8 Regression] ICE in gimplify_modify_expr, at
gimplify.c:5798
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed recently between 20180107 and 20180114.
Affects testfile gcc/testsuite/gfortran.dg/pr71230-1.f90 (and others).


$ gfortran-8-20180107 -c pr71230-1.f90 -O3 -ftrapv
$ gfortran-7-20180125 -c pr71230-1.f90 -O3 -ftrapv
$
$ gfortran-8-20180128 -c pr71230-1.f90 -O3 -ftrapv
during GIMPLE pass: vect
f951: internal compiler error: in gimplify_modify_expr, at gimplify.c:5798
0x97e137 gimplify_modify_expr
../../gcc/gimplify.c:5797
0x974a4b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11435
0x976d76 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6658
0x97947e gimplify_cond_expr
../../gcc/gimplify.c:4128
0x974a81 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11391
0x976d76 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6658
0x9791e5 gimplify_cond_expr
../../gcc/gimplify.c:4025
0x974a81 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11391
0x973b0b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12160
0x974ecc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12098
0x973aec gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12158
0x973aec gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12158
0x973aec gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12158
0x983e71 force_gimple_operand_1(tree_node*, gimple**, bool (*)(tree_node*),
tree_node*)
../../gcc/gimplify-me.c:78
0xd9ea3a vect_loop_versioning(_loop_vec_info*, unsigned int, bool, poly_int<1u,
unsigned long>)
../../gcc/tree-vect-loop-manip.c:3018
0xd8a83a vect_transform_loop(_loop_vec_info*)
../../gcc/tree-vect-loop.c:8607
0xdaf084 vectorize_loops()
../../gcc/tree-vectorizer.c:740

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[rsandifo at gcc dot gnu.org]

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

--- Comment #28 from rsandifo at gcc dot gnu.org  
---
(In reply to acsawdey from comment #27)
> So, I think the problem is that the rtx given by
> crtl->args.internal_arg_pointer is not canonical as expected. So near the
> beginning of vt_add_function_parameter where it is using == to compare parts
> of the incoming arg rtx to this, it fails but rtx_equal_p does not. This
> small patch resolves the go bootstrap issues:
> 
> Index: gcc/var-tracking.c
> ===
> --- gcc/var-tracking.c  (revision 257159)
> +++ gcc/var-tracking.c  (working copy)
> @@ -9668,10 +9668,10 @@
>   into MEMs based on the argument pointer, so that incoming doesn't
>   depend on a pseudo.  */
>if (MEM_P (incoming)
> -  && (XEXP (incoming, 0) == crtl->args.internal_arg_pointer
> +  && (rtx_equal_p (XEXP (incoming, 0), crtl->args.internal_arg_pointer)
>   || (GET_CODE (XEXP (incoming, 0)) == PLUS
> - && XEXP (XEXP (incoming, 0), 0)
> -== crtl->args.internal_arg_pointer
> + && rtx_equal_p (XEXP (XEXP (incoming, 0), 0),
> + crtl->args.internal_arg_pointer)
>   && CONST_INT_P (XEXP (XEXP (incoming, 0), 1)
>  {
>HOST_WIDE_INT off = -FIRST_PARM_OFFSET (current_function_decl);

Is this because we're using the pseudo-based split-stack code in
rs6000_internal_arg_pointer?  I'm not sure this test is meaningful
in that case: if the hook returns (plus (reg X) (const_int Y))
then presumably any offset applied to the pointer would be
(plus (reg X) (const_int Y')), which the code doesn't handle.

Or does the hook return a plain pseudo register in this case,
without any offset?  In that case I'd still have expected the
incoming_arg_pointer to be the pseudo rtx, so == ought to work.
It would be interesting to know why it doesn't.

[Bug fortran/84116] New: [7/8 Regression] ICE in gfc_match_omp_clauses, at fortran/openmp.c:1354

[gs...@t-online.de]

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

Bug ID: 84116
   Summary: [7/8 Regression] ICE in gfc_match_omp_clauses, at
fortran/openmp.c:1354
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects version 7 and 8 :

$ cat z1.f90
program p
   integer :: i
   !$omp simd linear ((i))
   do i = 1, 2
   end do
end

$ cat z2.f90
program p
   integer :: i
   !$omp simd linear (1)
   do i = 1, 2
   end do
end

$ cat z3.f90
program p
   integer :: i
   !$omp simd linear ()
   do i = 1, 2
   end do
end


$ gfortran-6 -c z1.f90 -fopenmp
z1.f90:3:22:

!$omp simd linear ((i))
  1
Error: Syntax error in OpenMP variable list at (1)


$ gfortran-8-20180128 -c z1.f90 -fopenmp
f951: internal compiler error: Segmentation fault
0xb94e5f crash_signal
../../gcc/toplev.c:325
0x6ec21d gfc_match_omp_clauses
../../gcc/fortran/openmp.c:1354
0x6ed6ce match_omp
../../gcc/fortran/openmp.c:2440
0x6ef8a4 gfc_match_omp_simd()
../../gcc/fortran/openmp.c:3249
0x6f51d9 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6f70cc match_word_omp_simd
../../gcc/fortran/parse.c:818
0x6f70cc decode_omp_directive
../../gcc/fortran/parse.c:824
0x6fad9a next_free
../../gcc/fortran/parse.c:1204
0x6fad9a next_statement
../../gcc/fortran/parse.c:1462
0x6fc0ec parse_spec
../../gcc/fortran/parse.c:3854
0x6fe5d3 parse_progunit
../../gcc/fortran/parse.c:5667
0x6ffbb4 gfc_parse_file()
../../gcc/fortran/parse.c:6207
0x7464ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/84115] [8 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'indirect_ref' in add_decl_as_local, at fortran/trans-decl.c:256

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

A few more testcases :


$ cat z2.f90
subroutine s(x)
   character(:), allocatable :: x
   associate (y => x)
  print *, y
   end associate
end


$ cat z3.f90
subroutine s(x)
   character(:), allocatable :: x
   associate (y => x//x)
  print *, y
   end associate
end


$ cat z4.f90
subroutine s(x)
   character(:), allocatable :: x
   associate (y => [x])
  print *, y
   end associate
end


$ cat z5.f90
subroutine s(x)
   character(:), allocatable :: x
   associate (y => [x,x])
  print *, y
   end associate
end

[Bug fortran/84115] New: [8 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'indirect_ref' in add_decl_as_local, at fortran/trans-decl.c:256

[gs...@t-online.de]

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

Bug ID: 84115
   Summary: [8 Regression] ICE: tree check: expected tree that
contains 'decl minimal' structure, have 'indirect_ref'
in add_decl_as_local, at fortran/trans-decl.c:256
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20170924 and 20171008.
Test version configured with --enable-checking=yes.
(different backtraces, depending on options and testfile,
when configured with --enable-checking=release)


$ cat z1.f90
subroutine s(x)
   character(:), allocatable :: x
   associate (y => x)
   end associate
end


$ gfortran-8-20180128 -c z1.f90
z1.f90:3:0:

associate (y => x)

internal compiler error: tree check: expected tree that contains 'decl minimal'
structure, have 'indirect_ref' in add_decl_as_local, at
fortran/trans-decl.c:256
0x61eecd tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/tree.c:9499
0x7a4fba contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3246
0x7a4fba add_decl_as_local
../../gcc/fortran/trans-decl.c:256
0x7a4fba gfc_finish_var_decl
../../gcc/fortran/trans-decl.c:617
0x7a3a50 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1779
0x7a7a77 generate_local_decl
../../gcc/fortran/trans-decl.c:5577
0x75ef0b do_traverse_symtree
../../gcc/fortran/symbol.c:4157
0x79cab2 generate_local_vars
../../gcc/fortran/trans-decl.c:5777
0x79cab2 gfc_process_block_locals(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6786
0x803e10 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2010
0x7753a7 trans_code
../../gcc/fortran/trans.c:1924
0x7a8b25 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6489
0x72ae90 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x72ae90 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x7721cf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug c/84108] [8 Regression] incorrect -Wattributes warning for packed/aligned conflict on struct members

[arnd at linaro dot org]

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

--- Comment #3 from Arnd Bergmann  ---
(In reply to Jakub Jelinek from comment #1)
> I vaguely remember the behavior of packed + aligned(N) kept changing in the
> past, some versions of GCC treated it just like packed, others as aligned.
> Is this in the kernel?

Yes. The example I showed corresponds to include/linux/sysv_fs.h, which
probably has very few users, if any. If this was inconsistent in the past, it
may have gone unnoticed. OTOH, there is a compile-time assertion in the code to
ensure that the structure has the right size:

#define __packed2__ __attribute__((packed,aligned(2)))
#define XENIX_NICINOD   100 /* number of inode cache entries */
#define XENIX_NICFREE   100 /* number of free block list chunk entries */
struct xenix_super_block {
__fs16  s_isize; /* index of first data zone */
__fs32  s_fsize __packed2__; /* total number of zones of this
fs */
/* the start of the free block list: */
__fs16  s_nfree;/* number of free blocks in s_free, <=
XENIX_NICFREE */
sysv_zone_t s_free[XENIX_NICFREE]; /* first free block list chunk
*/
/* the cache of free inodes: */
__fs16  s_ninode; /* number of free inodes in s_inode, <=
XENIX_NICINOD */
sysv_ino_t  s_inode[XENIX_NICINOD]; /* some free inodes */
/* locks, not used by Linux: */
chars_flock;/* lock during free block list
manipulation */
chars_ilock;/* lock during inode cache manipulation
*/
chars_fmod; /* super-block modified flag */
chars_ronly;/* flag whether fs is mounted read-only
*/
__fs32  s_time __packed2__; /* time of last super block update
*/
__fs32  s_tfree __packed2__; /* total number of free zones */
__fs16  s_tinode;   /* total number of free inodes */
__fs16  s_dinfo[4]; /* device information ?? */
chars_fname[6]; /* file system volume name */
chars_fpack[6]; /* file system pack name */
chars_clean;/* set to 0x46 when filesystem is
properly unmounted */
chars_fill[371];
s32 s_magic;/* version of file system */
__fs32  s_type; /* type of file system: 1 for 512 byte
blocks
2 for 1024 byte
blocks
3 for 2048 byte
blocks */

};
BUILD_BUG_ON(1024 != sizeof (struct xenix_super_block));

Two other variations of this warning that I ran into are slightly different:
fs/ubifs/ubifs-media.h and include/scsi/libsas.h define a structure with
__attribute__((packed)) and use that structure as a member in another
structure, with that member being marked __attribute__((aligned)). I would hope
that this behavior has never changed.

[Bug fortran/83975] [8 Regression] ICE in set_parm_default_def_partition, at tree-ssa-coalesce.c:1919

[gs...@t-online.de]

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

--- Comment #7 from G. Steinmetz  ---

Some additional testcases :


$ cat z2.f90
subroutine s(x)
   character(*) :: x
   associate (y => [x])
  print *, size(y), len(y), y
   end associate
end


$ cat z3.f90
subroutine s(x)
   character(*) :: x
   associate (y => [x, x])
  print *, y
   end associate
end


$ cat z4.f90
subroutine s(x)
   character(*) :: x
   associate (y => x)
  y = 'abc'
  print *, y
   end associate
end


$ cat z5.f90
subroutine s(x)
   character(*) :: x
   associate (y => x//x)
  print *, y
   end associate
end

[Bug tree-optimization/84090] [8 Regression] ICE in gimple_redirect_edge_and_branch, at tree-cfg.c:6151

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||aldyh at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #2 from Aldy Hernandez  ---
Can't reproduce either.

[Bug tree-optimization/84114] New: global reassociation pass prevents fma usage, generates slower code

[sje at gcc dot gnu.org]

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

Bug ID: 84114
   Summary: global reassociation pass prevents fma usage,
generates slower code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---

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

The example code comes from milc in SPEC2006.

GCC on x86 or aarch64 generates better code with -O3 than it does with -Ofast
or '-O3 -ffast-math'.  On x86 compiling with '-mfma -O3' I get 5 vfmadd231sd
instructions, 1 vmulsd instruction and 6 vmovsd.  With '-mfma -Ofast' I get 3
vfmadd231sd, 2 vaddsd, 3 vmulsd, and 6 vmovsd.  That is two extra instructions.

The problem seems to be that -Ofast turns on -ffast-math and that enables
the global reassociation pass (tree-ssa-reassoc.c) and the code changes
done there create some temporary variables which inhibit the recognition
and use of fma instructions.

Using -O3 and -Ofast on aarch64 shows the same change.

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #27 from acsawdey at gcc dot gnu.org ---
So, I think the problem is that the rtx given by
crtl->args.internal_arg_pointer is not canonical as expected. So near the
beginning of vt_add_function_parameter where it is using == to compare parts of
the incoming arg rtx to this, it fails but rtx_equal_p does not. This small
patch resolves the go bootstrap issues:

Index: gcc/var-tracking.c
===
--- gcc/var-tracking.c  (revision 257159)
+++ gcc/var-tracking.c  (working copy)
@@ -9668,10 +9668,10 @@
  into MEMs based on the argument pointer, so that incoming doesn't
  depend on a pseudo.  */
   if (MEM_P (incoming)
-  && (XEXP (incoming, 0) == crtl->args.internal_arg_pointer
+  && (rtx_equal_p (XEXP (incoming, 0), crtl->args.internal_arg_pointer)
  || (GET_CODE (XEXP (incoming, 0)) == PLUS
- && XEXP (XEXP (incoming, 0), 0)
-== crtl->args.internal_arg_pointer
+ && rtx_equal_p (XEXP (XEXP (incoming, 0), 0),
+ crtl->args.internal_arg_pointer)
  && CONST_INT_P (XEXP (XEXP (incoming, 0), 1)
 {
   HOST_WIDE_INT off = -FIRST_PARM_OFFSET (current_function_decl);

[Bug target/84077] [7/8 Regression] Likely wrong code with `__builtin_expect()` on i686-linux-gnu

[floessie.mail at gmail dot com]

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

--- Comment #5 from Flössie  ---
Created attachment 43278
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43278=edit
Complete -v output

[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  ---
For the avoidance of doubt:

C++98 did not support reading hex floats from an istream.

Libstdc++ still follows the C++98 spec, so does not read hex floats. "0x1" is
read as "0". "0x1p1" is also read as "0".

LWG 2381 is a (currently open) issue reported against the standard, saying that
the standard is not clear about whether reading hex floats is supposed to work.
The proposed fix is to add 'p' and 'P' to the list of atoms, and add examples
making it clear what should be parsed.

At this time LWG 2381 is still open. Until the proposed fix (or some other fix)
is resolved by making a change to the draft standard, I do not want to change
libstdc++.

When the C++ committee resolves LWG 2381 I will update libstdc++ to implement
the new rules.

[Bug libgcc/84113] gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311

[dougmencken at gmail dot com]

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

--- Comment #1 from Douglas Mencken  ---
ah yep, it’s at first stage

$ cat stage_current
stage1

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

[law at redhat dot com]

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

--- Comment #23 from Jeffrey A. Law  ---
I've got no objection Joseph.  But I think you need to make your case to Richi
and Jakub -- I doubt they're on CC for this BZ :-)

[Bug c/84108] [8 Regression] incorrect -Wattributes warning for packed/aligned conflict on struct members

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-29
  Known to work||5.1.0, 6.3.0, 7.2.0
Summary|incorrect -Wattributes  |[8 Regression] incorrect
   |warning for packed/aligned  |-Wattributes warning for
   |conflict|packed/aligned conflict on
   ||struct members
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #2 from Martin Sebor  ---
Confirmed.  Looks like I missed that the two attributes are treated differently
when used with struct members than with standalone objects.  Here's a test case
showing the differences and the expected/bogus warnings:

$ cat pr84108.c && gcc -O2 -S -Wall pr84108.c
#define A(e) _Static_assert (e, #e)

int i2 __attribute__((packed, aligned (2)));   // -Wattributes
int j2 __attribute__((aligned (2), packed));   // -Wattributes
int i1 __attribute__((aligned (2)));   // okay (reduces alignment)

A (_Alignof (i2) == 2);
A (_Alignof (j2) == 2);
A (_Alignof (i1) == 2); 

struct {
  int i2 __attribute__((packed, aligned (2)));   // bogus -Wattributes in GCC 8
  int j2 __attribute__((aligned (2), packed));   // bogus -Wattributes in GCC 8
  int i1 __attribute__((aligned (2)));   // ignored, no warning
} s;

A (_Alignof (s.i2) == 2);
A (_Alignof (s.j2) == 2);
A (_Alignof (s.i1) == 4);

pr84108.c:3:1: warning: ‘packed’ attribute ignored [-Wattributes]
 int i2 __attribute__((packed, aligned (2)));   // -Wattributes
 ^~~
pr84108.c:4:1: warning: ‘packed’ attribute ignored [-Wattributes]
 int j2 __attribute__((aligned (2), packed));   // -Wattributes
 ^~~
pr84108.c:12:3: warning: ignoring attribute ‘aligned’ because it conflicts with
attribute ‘packed’ [-Wattributes]
   int i2 __attribute__((packed, aligned (2)));   // bogus -Wattributes in GCC
8
   ^~~
pr84108.c:13:3: warning: ignoring attribute ‘packed’ because it conflicts with
attribute ‘aligned’ [-Wattributes]
   int j2 __attribute__((aligned (2), packed));   // bogus -Wattributes in GCC
8
   ^~~

[Bug c/83966] ICE in check_function_arguments at gcc/c-family/c-common.c:5617

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed for 8 and that's probably enough.

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

[joseph at codesourcery dot com]

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

--- Comment #22 from joseph at codesourcery dot com  ---
What do the m68k maintainers think about the suggestion of backporting to 
GCC 7 (and for that matter GCC 6)?  This is a regression in the sense of 
"libgcc used to build for ColdFire, then that broke", though not (as far 
as I know) a regression in the sense of "this fixed .i file used to build, 
then that broke".

[Bug libgomp/84088] [8 Regression][nvptx] libgomp.oacc-fortran/declare-*.f90 execution fails

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
(In reply to Tom de Vries from comment #5)
> Hmm. Probably this failure would have been picked up by
> libgomp-plugin-host_nonshm.

Hi Tom,

Although my patch caused it, I am not in a position to pick this one up - I am
unable to reproduce it and do not have access to the target you are using. In
addition, libgomp and all its workings are, as far as I am concerned, one of
the arcane mysteries of gcc.

I am perfectly happy to put in some time to help but I do not even know where
to start.

Sorry

Paul

[Bug c/83966] ICE in check_function_arguments at gcc/c-family/c-common.c:5617

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Mon Jan 29 18:20:01 2018
New Revision: 257159

URL: https://gcc.gnu.org/viewcvs?rev=257159=gcc=rev
Log:
PR c/83966
* c-format.c (check_function_format): Check current_function_decl.

* gcc.dg/format/Wsuggest-attribute-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/format/Wsuggest-attribute-1.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-format.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/84111] [8 Regression] Compile time hog w/ -O2

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Seems during cunroll we end up with:
y_8 = PHI 
...
y_29 = PHI 
...
y_37 = PHI 

where all 3 PHIs are degenerate and thus:
1539static tree
1540follow_copies_to_constant (tree var)
1541{
1542  tree res = var;
1543  while (TREE_CODE (res) == SSA_NAME)
1544{
1545  gimple *def = SSA_NAME_DEF_STMT (res);
1546  if (gphi *phi = dyn_cast  (def))
1547{
1548  if (tree rhs = degenerate_phi_result (phi))
1549res = rhs;
1550  else
1551break;
1552}
1553  else if (gimple_assign_single_p (def))
1554/* Will exit loop if not an SSA_NAME.  */
1555res = gimple_assign_rhs1 (def);
1556  else
1557break;
1558}

loops on that forever, with res being ... y_37, y_8, y_29, y_37, ...
emergency_dump_function at the point of looping:

foo (int x, int y, int z)
{
  int c;
  int * b;
  int a;
  unsigned int ivtmp_1;
  unsigned int ivtmp_2;
  int _4;
  unsigned int ivtmp_6;
  unsigned int ivtmp_13;
  unsigned int ivtmp_14;
  unsigned int ivtmp_16;
  unsigned int ivtmp_24;
  unsigned int ivtmp_27;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
;;succ:   15

;;   basic block 15, loop depth 0
;;pred:   2
  # y_25 = PHI 
  # a_3 = PHI <0(2)>
  # ivtmp_16 = PHI <2(2)>
  ivtmp_14 = ivtmp_27 - 1;
  if (ivtmp_24 != 0)
goto ; [100.00%]
  else
goto ; [0.00%]
;;succ:   16
;;7

;;   basic block 16, loop depth 0
;;pred:   15
;;succ:   17

;;   basic block 17, loop depth 1
;;pred:   16
;;19
  # y_10 = PHI 
  # a_17 = PHI <0(16), a_28(19)>
  # ivtmp_13 = PHI <36(16), ivtmp_2(19)>
  if (y_8 <= 0)
goto ; [89.00%]
  else
goto ; [11.00%]
;;succ:   10
;;18

;;   basic block 18, loop depth 1
;;pred:   17
  a_9 = a_38 + 1;
  ivtmp_6 = ivtmp_1 - 1;
  if (ivtmp_2 != 0)
goto ; [97.23%]
  else
goto ; [2.77%]
;;succ:   19
;;20

;;   basic block 19, loop depth 1
;;pred:   18
  goto ; [100.00%]
;;succ:   17

;;   basic block 20, loop depth 0
;;pred:   18
  # y_5 = PHI 
  goto ; [100.00%]
;;succ:   6

;;   basic block 11, loop depth 1
;;pred:   6
;;succ:   3

;;   basic block 3, loop depth 2
;;pred:   11
;;14
  # y_37 = PHI 
  # a_38 = PHI <0(11), a_28(14)>
  # ivtmp_1 = PHI <36(11), ivtmp_2(14)>
  if (y_8 <= 0)
goto ; [89.00%]
  else
goto ; [11.00%]
;;succ:   10
;;5

;;   basic block 10, loop depth 0
;;pred:   3
;;17
;;succ:   4

;;   basic block 4, loop depth 1
;;pred:   10
;;12
;;succ:   12

;;   basic block 12, loop depth 1
;;pred:   4
  goto ; [100.00%]
;;succ:   4

;;   basic block 5, loop depth 2
;;pred:   3
  a_28 = a_38 + 1;
  ivtmp_2 = ivtmp_1 - 1;
  if (ivtmp_2 != 0)
goto ; [97.23%]
  else
goto ; [2.77%]
;;succ:   14
;;13

;;   basic block 14, loop depth 2
;;pred:   5
  goto ; [100.00%]
;;succ:   3

;;   basic block 13, loop depth 1
;;pred:   5
  # y_29 = PHI 
;;succ:   6

;;   basic block 6, loop depth 1
;;pred:   20
;;13
  # y_8 = PHI 
  # a_12 = PHI <36(20), 36(13)>
  # ivtmp_27 = PHI 
  ivtmp_24 = ivtmp_27 - 1;
  if (0 != 0)
goto ; [0.00%]
  else
goto ; [100.00%]
;;succ:   11
;;7

;;   basic block 7, loop depth 0
;;pred:   6
;;15
  if (z_21(D) <= 32)
goto ; [94.50%]
  else
goto ; [5.50%]
;;succ:   8
;;9

;;   basic block 8, loop depth 0
;;pred:   7
  _4 ={v} MEM[(int *)0B];
  __builtin_trap ();
;;succ:  

;;   basic block 9, loop depth 0
;;pred:   7
  return;
;;succ:   EXIT

}

[Bug bootstrap/84113] New: gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311

[dougmencken at gmail dot com]

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

Bug ID: 84113
   Summary: gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler
error: in extract_insn, at recog.c:2311
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dougmencken at gmail dot com
  Target Milestone: ---

Created attachment 43277
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43277=edit
log

Can’t bootstrap release 7.3, 6.2 with the same configure (only 6.2 to 7.3 is
changed in prefix) was well

../gcc-7.3.0/configure \
--build=powerpc-unknown-darwin --host=powerpc-unknown-darwin
--target=powerpc-unknown-darwin \
--prefix=/Developer/GCC/7.3/PowerPC/32bit \
--enable-languages=c,c++,objc,obj-c++ \
--enable-shared --enable-static \
--enable-checking=release \
--enable-threads=posix --with-__thread --without-system-zlib \
--disable-nls --disable-werror

That’s what I got~
( more is here https://pastebin.com/nCgEusne and is attached )

../../../gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler error: in
extract_insn, at recog.c:2311
../../../gcc-7.3.0/libgcc/unwind.inc: In function '_Unwind_RaiseException':
../../../gcc-7.3.0/libgcc/unwind.inc:136:1: error: unrecognizable insn:

...

../../../gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler error: in
extract_insn, at recog.c:2311

[Bug c/70952] Missing warning for likely-erroneous octal escapes in string literals

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|REOPENED|NEW

--- Comment #8 from Eric Gallager  ---
(In reply to Alexander Monakov from comment #5)
> No, it's not a dup? Invalid octal literals outside of strings are already
> properly diagnosed, so the other bug talks about warning about them _as a
> matter of style_. This bug is about confusing use of octal literals in
> string constants. Compare:
> 
> char c=008;
> 
> error: invalid digit "8" in octal constant
> 
> char c[]="\008";
> 
> [silently accepted with -Wall -Wextra, emits a string literal of size 3]

(In reply to Alexander Monakov from comment #0)
> GCC doesn't warn for:
> 
> const char s[] = "\008";
> 
> (just the two zeros following the backslash become a part of the octal
> literal, so the string literal is equivalent to "\0""8")
> 
> \008 and \009 in string literals are most likely errors (\08 and \09 work
> just as well if a nil character followed by a digit was really intended)
> 
> I think a bit of a bikeshed is possible on the point how far we want to take
> it (do we warn for "\08"? for "\799"?).  I think warning when the octal
> escape with less than 3 digits is followed by [89] is desirable (this
> catches all of the above), but warning when octal escape already has 3
> digits may be not (this exempts "\0009" from the warning).

Oops, sorry, putting back in NEW

[Bug bootstrap/80867] gnat bootstrap broken on powerpc64le-linux-gnu with -O3

[kelvin at gcc dot gnu.org]

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

--- Comment #11 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Mon Jan 29 18:00:49 2018
New Revision: 257158

URL: https://gcc.gnu.org/viewcvs?rev=257158=gcc=rev
Log:
gcc/ChangeLog:

2018-01-29  Richard Biener 
Kelvin Nilsen  

PR bootstrap/80867
* tree-vect-stmts.c (vectorizable_call): Don't call
targetm.vectorize_builtin_md_vectorized_function if callee is
NULL.


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

[Bug tree-optimization/82965] [8 regression][armeb] gcc.dg/vect/pr79347.c starts failing after r254379

[amker at gcc dot gnu.org]

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

--- Comment #8 from amker at gcc dot gnu.org ---
I think there is inconsistent semantics between call in vect_do_peeling:
scale_loop_profile (prolog, prob_prolog, bound_prolog);
and implementation of scale_loop_profile.

When the loop is predicted to be executed too many times, scale_loop_profile
works in a way that messes up the count information.  The issue is worsened by
below code:
count_delta -= e->count ();
as well as sub behavior defined in
profile_count = (const profile_count )
  {
if (*this == profile_count::zero () || other == profile_count::zero ())
  return *this;
if (!initialized_p () || !other.initialized_p ())
  return *this = profile_count::uninitialized ();
else
  {
gcc_checking_assert (compatible_p (other));
m_val = m_val >= other.m_val ? m_val - other.m_val: 0;
m_quality = MIN (m_quality, other.m_quality);
  }
return *this;
  }

in which we return 0 if (count_delta < e->count ()), which is always the case
because the new iteration bound is smaller than the original guessed one.

Given scale_loop_profile is only used by vect_do_peeling, I will see how we
should rewrite it in align with caller's semantics.

Thanks.

[Bug target/84112] [8 Regression] powerpc64le ICE in LRA on openjdk

[vmakarov at gcc dot gnu.org]

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

--- Comment #1 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #0)
> The following testcase ICEs with -mcpu=power8 -O3 -fstack-protector-strong
> -fpic on powerpc64le-linux with:
> rh1539812.i: In function ‘foo’:
> rh1539812.i:30:1: internal compiler error: in lra_set_insn_recog_data, at
> lra.c:998
>  }
>  ^
>

I started to work on it.  I think the fix will be ready tomorrow.

[Bug tree-optimization/84111] [8 Regression] Compile time hog w/ -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/84111] [8 Regression] Compile time hog w/ -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-29
 CC||jakub at gcc dot gnu.org,
   ||matz at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r255467.

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
The purpose of the warning is to detect coding mistakes.  There is no valid use
case for declaring the same function const and pure so it must be a mistake. 
As the test case shows, the mistake can lead to subtle bugs.

In this instance, the warning is a false positive caused by bug 83871 showing
that the C++ front end applies the attribute from the primary template to its
specialization.  That's what should be fixed.  Suppressing the warning by
removing the conflicting attribute would only mask that underlying bug.

If I'm reading Jason's patch in attachment 43275 right, it handles the
underlying problem (i.e., fixes bug 83871).  I'll try to find time to finish it
up.

[Bug c/84108] incorrect -Wattributes warning for packed/aligned conflict

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
I vaguely remember the behavior of packed + aligned(N) kept changing in the
past, some versions of GCC treated it just like packed, others as aligned.
Is this in the kernel?