[Bug sanitizer/80403] UBSAN: compile time crash with "type mismatch in binary expression" message in / and % expr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-12
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug sanitizer/80404] UBSAN: compile time crash with "non-trivial conversion at assignment" error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-12
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug sanitizer/80405] UBSAN: compile time crash with "type mismatch in shift expression" error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-12
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/80294] [5/6 Regression] ICE with constexpr and inheritance

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE with |[5/6 Regression] ICE with
   |constexpr and inheritance   |constexpr and inheritance

--- Comment #18 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug fortran/80361] [5/6/7 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from janus at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #14)
> Should we simply make these proxedures recursive?

Yes, I think the generated finalizers simply need to be recursive in cases like
these. I can take care of that.


> Does anybody know what the standard says?

I guess the standard does not say anything about procedures that gfortran
generates for its internal implementation ...

[Bug go/77857] gccgo: vendoring doesn't work in gcc 6/7

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Should be fixed at last, on trunk.

[Bug go/77857] gccgo: vendoring doesn't work in gcc 6/7

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Apr 12 04:26:15 2017
New Revision: 246864

URL: https://gcc.gnu.org/viewcvs?rev=246864=gcc=rev
Log:
PR go/77857
cmd/go: generate vendor paths for -I arg on compile

This change generates the vendor path to be used with -I
on a gccgo compile to find imports from the vendor directories.

Fixes golang/go#15628

Reviewed-on: https://go-review.googlesource.com/39590

Modified:
trunk/libgo/go/cmd/go/build.go

[Bug c/80406] New: Reduced false positive test case for -Warray-bounds with -O3

[brlcad at mac dot com]

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

Bug ID: 80406
   Summary: Reduced false positive test case for -Warray-bounds
with -O3
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brlcad at mac dot com
  Target Milestone: ---

Created attachment 41182
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41182=edit
False positive, compile with: gcc -Warray-bounds -O3 -c
gcc_6-2-1_compiler_bug.c

This is yet another report of an -Warray-bounds false positive when compiling
with -O3.

Scanned possible dupes and there are obviously lots similar still open (e.g.,
63213, 66974, 77291), but none that seem (to me) exactly like the case I
encountered compiling BRL-CAD with 6.2.1 and 5.4.0.  I've reduced the code in
question and annotated the logic flow, attached.

Warning is not issued below -O3.  Warning is not issued with a boundary test
(npts <= MAX_HITS) in the "WARN PARENT LOOP".  In fact, changing nearly any
aspect of this simplified case seems to make the warning go away.

Particularly interesting, a warning is not issued if "ASSURANCE B" is enabled
on this simplified example, though it DOESN't quell our production code.  This
is interesting because it means the optimizer is (probably) correctly
identifying Assurance B as dead/unnecessary code, but then subsequently warns
in the WARN LOOP.

[Bug target/80382] ICE with error: unrecognizable insn

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #10 from Segher Boessenkool  ---
I have a patch.

[Bug fortran/80388] ICE in output_constructor_regular_field, at varasm.c:4986

[Glenn.Hyland at utas dot edu.au]

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

--- Comment #4 from Glenn Hyland  ---
Thanks. I'm already at the latest gFortran release for my platform "Ubuntu
16.04.2 LTS". Not prepared at this stage to go to a development version of
Ubuntu that would include a newer compiler version.

I'm happy to use the workaround that gives me a working solution, and to make a
note about the potential problem with pre-6.3.1 versions of the compiler.
Thanks for your help.

[Bug sanitizer/80405] New: UBSAN: compile time crash with "type mismatch in shift expression" error

[babokin at gmail dot com]

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

Bug ID: 80405
   Summary: UBSAN: compile time crash with "type mismatch in shift
expression" error
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

gcc x86_64, top of the trunk.

> cat f.cpp
extern unsigned int var_60, var_110;
void foo() {
var_110 = (!~0 >= unsigned(0 < 0)) << var_60;
}

> g++ -fsanitize=undefined -w -O0 -c f.cpp
f.cpp: In function ‘void foo()’:
f.cpp:2:6: error: type mismatch in shift expression
 void foo() {
  ^~~
int
unsigned int
unsigned int
_2 = 1 << var_60.0;
f.cpp:2:6: internal compiler error: verify_gimple failed
<...>

[Bug sanitizer/80404] New: UBSAN: compile time crash with "non-trivial conversion at assignment" error

[babokin at gmail dot com]

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

Bug ID: 80404
   Summary: UBSAN: compile time crash with "non-trivial conversion
at assignment" error
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

gcc x86_64, top of the trunk.

> cat f.cpp
extern short var_54;
unsigned foo() {
  unsigned a = (0 < 0 >= (0 >= 0)) / unsigned(var_54);
  return a;
}

> g++ -fsanitize=undefined -w -O0 -c f.cpp
f.cpp: In function ‘unsigned int foo()’:
f.cpp:2:10: error: non-trivial conversion at assignment
 unsigned foo() {
  ^~~
unsigned int
int
a = 0;
f.cpp:2:10: internal compiler error: verify_gimple failed
<...>

[Bug sanitizer/80403] New: UBSAN: compile time crash with "type mismatch in binary expression" message in / and % expr

[babokin at gmail dot com]

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

Bug ID: 80403
   Summary: UBSAN: compile time crash with "type mismatch in
binary expression" message in / and % expr
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

gcc x86_64, top of the trunk with patch from 80349. This seems related, but
different.

> cat f.cpp
unsigned foo() {
   unsigned a = unsigned(!(6044238 >> 0) >= (0 < 0)) % 0;
   unsigned b = unsigned(!(6044238 >> 0) >= (0 < 0)) / 0;
   return a+b;
}

> g++ -fsanitize=undefined -w -O0 -c f.cpp
f.cpp: In function ‘unsigned int foo()’:
f.cpp:1:10: error: type mismatch in binary expression
 unsigned foo() {
  ^~~
unsigned int

int

unsigned int

a = 1 % 0;
f.cpp:1:10: error: type mismatch in binary expression
unsigned int

int

unsigned int

b = 1 / 0;
f.cpp:1:10: internal compiler error: verify_gimple failed

[Bug fortran/80388] ICE in output_constructor_regular_field, at varasm.c:4986

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
  Known to work||6.3.1, 7.0
  Known to fail||5.4.0

--- Comment #3 from kargl at gcc dot gnu.org ---
The code compiles and gives the correct answer with 
GNU Fortran (GCC) 6.3.1 20170207
GNU Fortran (GCC) 7.0.1 20170407

I doubt that the patch will be back-ported to 5-branch
as there are too few gfortran developers.  Can you 
update to a newer compiler.

[Bug rtl-optimization/80352] Improper reload of operands with equiv pseudo

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
(In reply to Vladimir Makarov from comment #2)
> Thank you for the report.  I'll investigate the problem.  A few hours ago
> I've committed an additional patch.  It might solve the problem.  I'll check
> it.

Sorry. I put this comment in the wrong place.

[Bug target/80402] New: Missed optimization on x86/x86_64

[mednafen at sent dot com]

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

Bug ID: 80402
   Summary: Missed optimization on x86/x86_64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mednafen at sent dot com
  Target Milestone: ---
Target: x86_64

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

A statement like "if(!(a & 0xF) || (b & (1U << 6)))" could be compiled to a
"test","bt" pair followed by a single conditional branch/move instruction, but
gcc currently compiles it to a combination of two tests and conditional
branch/move instructions.

From
https://software.intel.com/sites/default/files/managed/ad/01/253666-sdm-vol-2a.pdf
Page 3-114, BT: "The ZF flag is unaffected."

Old versions(prior to early 2010, as far as I can tell) of the manual had the
flag as being undefined, so it may be prudent to talk to Intel and AMD
engineers before implementing this optimization.

Attached is sample code that includes the optimal form via inline
assembly(test4() function).

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

[glisse at gcc dot gnu.org]

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

--- Comment #17 from Marc Glisse  ---
(In reply to Jason Merrill from comment #16)
> (In reply to Marc Glisse from comment #13)
> > it seems better than abusing __builtin_constant_p, which is getting
> > contradictory requirements from its various uses:
> > - constexpr (forces very early lowering)
> 
> I'm not sure what you mean here; constexpr specifically delays lowering
> within a constexpr function until we're actually trying to evaluate to a
> constant value.

Evaluating a constexpr function forces the front-end to evaluate
__builtin_constant_p. That's very early compared to usual __builtin_constant_p
lowering during gimple optimizations. However, now that I think about it, I
can't remember why I thought this would be an issue. constexpr evaluation only
happens when required, not as an optimization, and when it happens the whole
function gets evaluated at compile-time, so I can't think of when we would miss
an optimization this way...

[Bug rtl-optimization/80352] Improper reload of operands with equiv pseudo

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
Thank you for the report.  I'll investigate the problem.  A few hours ago I've
committed an additional patch.  It might solve the problem.  I'll check it.

[Bug fortran/80388] ICE in output_constructor_regular_field, at varasm.c:4986

[Glenn.Hyland at utas dot edu.au]

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

--- Comment #2 from Glenn Hyland  ---
Sorry - hit return too early. Example code below (example.f90) generates ICE at
varasm.c:4986 ...

program example

integer, parameter :: r8 = selected_real_kind(14,30)

type test
real (r8) :: computation_accuracy
real (r8), dimension(2) :: values
end type test

type(test) :: temp

data temp / test( 10, (/8, 1/) ) /  ! this gives an ICE

print *, temp

return
end

$ gfortran -c example.f90
example.f90:17:0:

 end
 ^
internal compiler error: in output_constructor_regular_field, at varasm.c:4986
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Replacing the data declaration line with ...

data temp / test( 10_r8, (/8_r8, 1_r8/) ) / ! compiles - prints wrong
result

allows the program to be compiled, but gives the wrong result.

$ gfortran -c example.f90
$ gfortran example.o -o example
$ ./example 
   4.9406564584124654E-323   3.9525251667299724E-323   4.9406564584124654E-324

Replacing the data declaration line with ...

data temp / test( 10._r8, (/8._r8, 1._r8/) ) /  ! this is ok

is ok - compiles without error and prints the right result.

$ ./example 
   10.0008.1.

[Bug rtl-optimization/80401] [7 regression] gcc.target/powerpc/dimode_off.c and gcc.target/powerpc/pr79038-1.c fail starting with r246764

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug fortran/80361] [5/6/7 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[tkoenig at gcc dot gnu.org]

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

--- Comment #14 from Thomas Koenig  ---
(In reply to janus from comment #12)
> Created attachment 41179 [details]
> reduced test case
> 
> I managed to boil down the test case to a more compact form, see the
> attached file.
> 
> Note that it does not contain any FINAL procedure any more. The error
> message ...
> 
> Fortran runtime error: Recursive call to nonrecursive procedure
> '__final_particle_specifiers_Prt_spec_list_t'
> 
> ... refers to the a finalization procedure generated by gfortran, which is
> also used for polymorphic deallocation.

Should we simply make these proxedures recursive?

Does anybody know what the standard says?

[Bug middle-end/77671] missing -Wformat-overflow warning on sprintf overflow with "%s"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-11
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
Testing a patch.

[Bug target/80315] Calling __builtin_crypto_vshasigmaw with argument 3 out of range creates an unrecognizable insn

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
Backports still needed.

[Bug target/80376] Some vec_xxpermdi usage lead to ICE

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
Backports still needed.

[Bug target/80376] Some vec_xxpermdi usage lead to ICE

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Author: wschmidt
Date: Tue Apr 11 21:37:16 2017
New Revision: 246859

URL: https://gcc.gnu.org/viewcvs?rev=246859=gcc=rev
Log:
2017-04-11  Bill Schmidt  

PR target/80376
PR target/80315
* config/rs6000/rs6000.c (rs6000_expand_unop_builtin): Return
CONST0_RTX (mode) rather than const0_rtx where appropriate.
(rs6000_expand_binop_builtin): Likewise.
(rs6000_expand_ternop_builtin): Likewise; also add missing
vsx_xxpermdi_* variants; also fix typo (arg1 => arg2) for
vshasigma built-ins.
* doc/extend.texi: Document that vec_xxpermdi's third argument
must be a constant.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/doc/extend.texi

[Bug target/80315] Calling __builtin_crypto_vshasigmaw with argument 3 out of range creates an unrecognizable insn

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
Author: wschmidt
Date: Tue Apr 11 21:37:16 2017
New Revision: 246859

URL: https://gcc.gnu.org/viewcvs?rev=246859=gcc=rev
Log:
2017-04-11  Bill Schmidt  

PR target/80376
PR target/80315
* config/rs6000/rs6000.c (rs6000_expand_unop_builtin): Return
CONST0_RTX (mode) rather than const0_rtx where appropriate.
(rs6000_expand_binop_builtin): Likewise.
(rs6000_expand_ternop_builtin): Likewise; also add missing
vsx_xxpermdi_* variants; also fix typo (arg1 => arg2) for
vshasigma built-ins.
* doc/extend.texi: Document that vec_xxpermdi's third argument
must be a constant.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/doc/extend.texi

[Bug target/80098] ICE in curr_insn_transform, at lra-constraints.c:3816 on ppc64le

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Created attachment 41180
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41180=edit
Proposed patch to fix the problem

[Bug c++/80294] [5/6/7 Regression] ICE with constexpr and inheritance

[jason at gcc dot gnu.org]

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

--- Comment #17 from Jason Merrill  ---
Author: jason
Date: Tue Apr 11 21:07:32 2017
New Revision: 246858

URL: https://gcc.gnu.org/viewcvs?rev=246858=gcc=rev
Log:
PR c++/80294 - ICE with constexpr and inheritance.

* constexpr.c (reduced_constant_expression_p):
A null constructor element is non-constant.
(cxx_eval_indirect_ref): Don't VERIFY_CONSTANT before
returning an empty base.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-empty3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug target/80382] ICE with error: unrecognizable insn

[bergner at gcc dot gnu.org]

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

--- Comment #9 from Peter Bergner  ---
It seems you can call creduce multiple times and see some reduction.  Here's a
reduced test case:

bergner@pike:~/gcc/BUGS/PR80382$ cat bug.ii
namespace a {
typedef enum {} b;
template  struct g {
  c d;
  g(c) {}
  b f;
  void i() {
c a;
__atomic_load(, , f);
  }
};
}
namespace ad {
using a::g;
}
using ad::g;
class k {
  int *ak;
  int h;
};
class l {
public:
  template  l(j);
};
class m {
public:
  m() : as(k()), au(1) { as.i(); }
  g as;
  l au;
};
enum av : int;
class n {
public:
  n(int, av);
};
class G {
  G();
  bool ay;
  m e;
  n bf;
};
enum av : int { bg };
int bh();
G::G() : bf(bh(), bg) {}
bergner@pike:~/gcc/BUGS/PR80382$
/home/bergner/gcc/build/gcc-fsf-mainline-pr80382-debug/gcc/xg++
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr80382-debug/gcc -O3 -std=c++11
-mtune=power8 -mcpu=power8 -mno-lra -S bug.ii
bug.ii: In constructor ‘G::G()’:
bug.ii:44:24: error: unrecognizable insn:
 G::G() : bf(bh(), bg) {}
^
(insn 12 11 13 2 (set (reg:PTI 165)
(unspec:PTI [
(mem/v:TI (plus:DI (reg/f:DI 161 [ this ])
(const_int 8 [0x8])) [-1  S16 A128])
] UNSPEC_LSQ)) "bug.ii":9 -1
 (nil))
bug.ii:44:24: internal compiler error: in extract_insn, at recog.c:2311
0x110c3cf7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/bergner/gcc/gcc-fsf-mainline-pr80382/gcc/rtl-error.c:108
0x110c3d6b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/bergner/gcc/gcc-fsf-mainline-pr80382/gcc/rtl-error.c:116
0x1104ac5b extract_insn(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-pr80382/gcc/recog.c:2311
0x10c0063f instantiate_virtual_regs_in_insn
/home/bergner/gcc/gcc-fsf-mainline-pr80382/gcc/function.c:1589
0x10c0260f instantiate_virtual_regs
/home/bergner/gcc/gcc-fsf-mainline-pr80382/gcc/function.c:1957
0x10c027af execute
/home/bergner/gcc/gcc-fsf-mainline-pr80382/gcc/function.c:2006
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/80401] [7 regression] gcc.target/powerpc/dimode_off.c and gcc.target/powerpc/pr79038-1.c fail starting with r246764

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
That transformation will definitely degrade performance...

[Bug target/80315] Calling __builtin_crypto_vshasigmaw with argument 3 out of range creates an unrecognizable insn

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-11
   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Bill Schmidt  ---
Confirmed.  This is just due to a silly typo.

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

[jason at gcc dot gnu.org]

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

--- Comment #16 from Jason Merrill  ---
(In reply to Marc Glisse from comment #13)
> it seems better than abusing __builtin_constant_p, which is getting
> contradictory requirements from its various uses:
> - constexpr (forces very early lowering)

I'm not sure what you mean here; constexpr specifically delays lowering within
a constexpr function until we're actually trying to evaluate to a constant
value.

[Bug rtl-optimization/80401] [7 regression] gcc.target/powerpc/dimode_off.c and gcc.target/powerpc/pr79038-1.c fail starting with r246764

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Target||powerpc*-*-*
 CC||vmakarov at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Host||powerpc*-*-*
  Build||powerpc*-*-*

--- Comment #1 from seurer at gcc dot gnu.org ---
Note: this occurs on both BE and LE for powerpc64.

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

[jason at gcc dot gnu.org]

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

--- Comment #15 from Jason Merrill  ---
(In reply to Pedro Alves from comment #6)
> Hmm.  I'd argue that __builtin_constant_p (s) should return true in that case,
> since we're in a constexpr?

No, the compiler is right; the address of the local array variable is not
constant, only its contents.

[Bug rtl-optimization/80401] New: [7 regression] gcc.target/powerpc/dimode_off.c and gcc.target/powerpc/pr79038-1.c fail starting with r246764

[seurer at gcc dot gnu.org]

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

Bug ID: 80401
   Summary: [7 regression] gcc.target/powerpc/dimode_off.c and
gcc.target/powerpc/pr79038-1.c fail starting with
r246764
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

The failing tests are looking for specific assembler instructions (or lack of
them) and the revision changed lots of generated code sequences.  For instance,
in dimode_off it changes

addi 9,3,32767
std 4,0(9)

to

mtvsrd 0,4
stfd 0,32767(3)


Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/   -fno-diagnostics-show-caret
-fdiagnostics-color=never  -O2 -fno-align-functions -mtraceback=no -save-temps
-ffat-lto-objects -c   -o dimode_off.o
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/dimode_off.c   
(timeout = 300)
spawn /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/ -fno-diagnostics-show-caret
-fdiagnostics-color=never -O2 -fno-align-functions -mtraceback=no -save-temps
-ffat-lto-objects -c -o dimode_off.o
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/dimode_off.c
PASS: gcc.target/powerpc/dimode_off.c (test for excess errors)
size is size
Executing on host: size dimode_off.o   (timeout = 300)
spawn size dimode_off.o
   textdata bss dec hex filename
440   0   0 440 1b8 dimode_off.o
text size is 440
PASS: gcc.target/powerpc/dimode_off.c object-size text == 440
FAIL: gcc.target/powerpc/dimode_off.c scan-assembler-not (st|l)fd


Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/pr79038-1.c  
-fno-diagnostics-show-caret -fdiagnostics-color=never  -mcpu=power9 -O2
-mfloat128 -ffat-lto-objects -S   -o pr79038-1.s(timeout = 300)
spawn /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/pr79038-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -mcpu=power9 -O2
-mfloat128 -ffat-lto-objects -S -o pr79038-1.s
PASS: gcc.target/powerpc/pr79038-1.c (test for excess errors)
FAIL: gcc.target/powerpc/pr79038-1.c scan-assembler \\mlxsi[bh]zx\\M
PASS: gcc.target/powerpc/pr79038-1.c scan-assembler \\mvexts[bh]2d\\M
PASS: gcc.target/powerpc/pr79038-1.c scan-assembler-not \\mextsb\\M
FAIL: gcc.target/powerpc/pr79038-1.c scan-assembler-not \\ml[bh][az]\\M
FAIL: gcc.target/powerpc/pr79038-1.c scan-assembler-not \\mmtvsrw[az]\\M

[Bug c++/80370] [7 Regression] ICE when using structured bindings and nested generic lambdas (tsubst_decomp_names)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/80370] [7 Regression] ICE when using structured bindings and nested generic lambdas (tsubst_decomp_names)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 11 20:51:16 2017
New Revision: 246857

URL: https://gcc.gnu.org/viewcvs?rev=246857=gcc=rev
Log:
PR c++/80370
* decl.c (cp_finish_decomp): If processing_template_decl on
non-dependent decl, only set TREE_TYPE on the v[i] decls, but don't
change their DECL_VALUE_EXPR nor cp_finish_decl them.  Instead make
sure DECL_VALUE_EXPR is the canonical NULL type ARRAY_REF for tsubst
processing.
* pt.c (value_dependent_expression_p) : For variables
with DECL_VALUE_EXPR, return true if DECL_VALUE_EXPR is type
dependent.

* g++.dg/cpp1z/decomp28.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/decomp28.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/80361] [5/6/7 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #13 from janus at gcc dot gnu.org ---
(In reply to janus from comment #12)
> I managed to boil down the test case to a more compact form, see the
> attached file.

... and finally reduced to the bare minimum:


program main_ut

  implicit none

  type :: prt_spec_expr_t
  end type

  type :: prt_expr_t
 class(prt_spec_expr_t), allocatable :: x
  end type

  type, extends (prt_spec_expr_t) :: prt_spec_list_t
 type(prt_expr_t) :: e
  end type

  class(prt_spec_list_t), allocatable :: y

  allocate (y)
  allocate (prt_spec_list_t :: y%e%x)
  deallocate(y)

end program

[Bug rtl-optimization/70478] [LRA] S/390: Performance regression - superfluous stack frame

[vmakarov at gcc dot gnu.org]

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

--- Comment #11 from Vladimir Makarov  ---
Author: vmakarov
Date: Tue Apr 11 19:39:59 2017
New Revision: 246854

URL: https://gcc.gnu.org/viewcvs?rev=246854=gcc=rev
Log:
2017-04-11  Vladimir Makarov  

PR rtl-optimization/70478
* lra-constraints.c (process_alt_operands): Check memory for
disfavoring memory insn operand.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

[Bug c/80400] missing -Wattributes on a invalid attribute packed on a typedef

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
See also bug 80398 for another missing -Wattributes warning on an ignored
attribute packed.

[Bug fortran/80361] [5/6/7 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #12 from janus at gcc dot gnu.org ---
Created attachment 41179
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41179=edit
reduced test case

I managed to boil down the test case to a more compact form, see the attached
file.

Note that it does not contain any FINAL procedure any more. The error message
...

Fortran runtime error: Recursive call to nonrecursive procedure
'__final_particle_specifiers_Prt_spec_list_t'

... refers to the a finalization procedure generated by gfortran, which is also
used for polymorphic deallocation.

[Bug c/80400] New: missing -Wattributes on a invalid attribute packed on a typedef

[msebor at gcc dot gnu.org]

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

Bug ID: 80400
   Summary: missing -Wattributes on a invalid attribute packed on
a typedef
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The description of attribute packed in the GCC manual states that:

You may only specify the packed attribute attribute on the definition of an
enum, struct or union, not on a typedef that does not also define the
enumerated type, structure or union. 

In most cases, GCC (in C mode) also issues a warning when the attribute is
specified on a typedef where it is ignored.  However, when the attribute
appears after the struct keyword in the typedef GCC fails to issue the expected
warning.  G++ has no such problem.

  typedef struct __attribute__ ((packed)) S S1;   // missing warning in C

$ (set -x && cat a.c && for lang in c c++; do gcc -S -Wall -Wextra -Wpedantic
-Wattributes -Wignored-attributes -x$lang a.c; done)
+ cat a.c
struct S { int i; char c; };

typedef __attribute__ ((packed)) struct S S0;
typedef struct __attribute__ ((packed)) S S1;   // missing warning in C
typedef struct S __attribute__ ((packed)) S2;
typedef struct S S3 __attribute__ ((packed));

#if __cplusplus
#  define A(e) static_assert(e, #e)
#else
#  define A(e) _Static_assert(e, #e)
#endif

A (sizeof (S0) == 1);
A (sizeof (S1) == 1);
A (sizeof (S2) == 1);
A (sizeof (S3) == 1);

+ for lang in c c++
+ gcc -S -Wall -Wextra -Wpedantic -Wattributes -Wignored-attributes -xc a.c
a.c:3:41: warning: ‘packed’ attribute ignored [-Wattributes]
 typedef __attribute__ ((packed)) struct S S0;
 ^
a.c:5:16: warning: ‘packed’ attribute ignored [-Wattributes]
 typedef struct S __attribute__ ((packed)) S2;
^
a.c:6:16: warning: ‘packed’ attribute ignored [-Wattributes]
 typedef struct S S3 __attribute__ ((packed));
^
a.c:11:16: error: static assertion failed: "sizeof (S0) == 1"
 #  define A(e) _Static_assert(e, #e)
^
a.c:14:1: note: in expansion of macro ‘A’
 A (sizeof (S0) == 1);
 ^
a.c:11:16: error: static assertion failed: "sizeof (S1) == 1"
 #  define A(e) _Static_assert(e, #e)
^
a.c:15:1: note: in expansion of macro ‘A’
 A (sizeof (S1) == 1);
 ^
a.c:11:16: error: static assertion failed: "sizeof (S2) == 1"
 #  define A(e) _Static_assert(e, #e)
^
a.c:16:1: note: in expansion of macro ‘A’
 A (sizeof (S2) == 1);
 ^
a.c:11:16: error: static assertion failed: "sizeof (S3) == 1"
 #  define A(e) _Static_assert(e, #e)
^
a.c:17:1: note: in expansion of macro ‘A’
 A (sizeof (S3) == 1);
 ^
+ for lang in c c++
+ gcc -S -Wall -Wextra -Wpedantic -Wattributes -Wignored-attributes -xc++ a.c
a.c:3:43: warning: ‘packed’ attribute ignored [-Wattributes]
 typedef __attribute__ ((packed)) struct S S0;
   ^~
a.c:4:41: warning: attributes ignored on elaborated-type-specifier that is not
a forward declaration [-Wattributes]
 typedef struct __attribute__ ((packed)) S S1;
 ^
a.c:5:43: warning: ‘packed’ attribute ignored [-Wattributes]
 typedef struct S __attribute__ ((packed)) S2;
   ^~
a.c:6:44: warning: ‘packed’ attribute ignored [-Wattributes]
 typedef struct S S3 __attribute__ ((packed));
^
a.c:9:16: error: static assertion failed: sizeof (S0) == 1
 #  define A(e) static_assert(e, #e)
^
a.c:14:1: note: in expansion of macro ‘A’
 A (sizeof (S0) == 1);
 ^
a.c:9:16: error: static assertion failed: sizeof (S1) == 1
 #  define A(e) static_assert(e, #e)
^
a.c:15:1: note: in expansion of macro ‘A’
 A (sizeof (S1) == 1);
 ^
a.c:9:16: error: static assertion failed: sizeof (S2) == 1
 #  define A(e) static_assert(e, #e)
^
a.c:16:1: note: in expansion of macro ‘A’
 A (sizeof (S2) == 1);
 ^
a.c:9:16: error: static assertion failed: sizeof (S3) == 1
 #  define A(e) static_assert(e, #e)
^
a.c:17:1: note: in expansion of macro ‘A’
 A (sizeof (S3) == 1);
 ^

[Bug tree-optimization/80397] missing -Wformat-overflow with arguments of enum types

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization, patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-11
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00547.html

[Bug middle-end/80399] New: Premature optimization with unsigned

[pinskia at gcc dot gnu.org]

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

Bug ID: 80399
   Summary: Premature optimization with unsigned
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take the following two functions:
unsigned f(unsigned t)
{
  t = (t - 1)*16;
  t = t/16;
  return t;
}
unsigned g(unsigned t)
{
  t = t - 1;
  t = t*16;
  t = t/16;
  return t;
}


They should produce the same code but they don't.
On aarch64 for an example we produce:
f:
mov w1, 268435455
add w0, w0, w1
and w0, w0, w1
ret

g:
sub w0, w0, #1
and w0, w0, 268435455
ret


g is better than f here since we have only one dependent instruction instead of
2.

[Bug sanitizer/80349] [6/7 Regression] UBSAN: compile time crash with "type mismatch in binary expression" message

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 41178
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41178=edit
gcc7-pr80349.patch

Untested fix.

[Bug c/80398] New: missing -Wattributes on a misplaced attribute packed in an enum definition

[msebor at gcc dot gnu.org]

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

Bug ID: 80398
   Summary: missing -Wattributes on a misplaced attribute packed
in an enum definition
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC (in C mode) fails to diagnose the following declaration with the misplaced
packed attribute in the test case below.  G++ issues the expected warning.

  __attribute__ ((packed)) enum E0 { e0 };   // attribute ignored, missing
warning

$ (set -x && cat a.c && for lang in c c++; do gcc -S -Wall -Wextra -Wpedantic
-Wattributes -Wignored-attributes -x$lang a.c; done)
+ cat a.c
__attribute__ ((packed)) enum E0 { e0 };
enum __attribute__ ((packed)) E1 { e1 }; 
enum E2 { e2 } __attribute__ ((packed));

#if __cplusplus
#  define A(e) static_assert (e, #e)
#else
#  define A(e) _Static_assert (e, #e)
#endif

A (sizeof (enum E0) == 1);
A (sizeof (enum E1) == 1);
A (sizeof (enum E2) == 1);
+ for lang in c c++
+ gcc -S -Wall -Wextra -Wpedantic -Wattributes -Wignored-attributes -xc a.c
a.c:8:16: error: static assertion failed: "sizeof (enum E0) == 1"
 #  define A(e) _Static_assert (e, #e)
^
a.c:11:1: note: in expansion of macro ‘A’
 A (sizeof (enum E0) == 1);
 ^
+ for lang in c c++
+ gcc -S -Wall -Wextra -Wpedantic -Wattributes -Wignored-attributes -xc++ a.c
a.c:1:31: warning: attribute ignored in declaration of ‘enum E0’ [-Wattributes]
 __attribute__ ((packed)) enum E0 { e0 };
   ^~
a.c:1:31: note: attribute for ‘enum E0’ must follow the ‘enum’ keyword
a.c:6:16: error: static assertion failed: sizeof (enum E0) == 1
 #  define A(e) static_assert (e, #e)
^
a.c:11:1: note: in expansion of macro ‘A’
 A (sizeof (enum E0) == 1);
 ^

[Bug fortran/80392] ICE with allocatable polymorphic function result in a procedure pointer component

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-11
 CC||janus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
The change occurred between revisions r242391 (2016-11-14, error) and r242749
(2016-11-23, ICE), may be r242392 (pr78300).

Compiling the test with an instrumented gfortran gives

ASAN:DEADLYSIGNAL
=
==68236==ERROR: AddressSanitizer: stack-overflow on address 0x7fff5bc00f68 (pc
0x0001523fe4c6 bp 0x7fff5bc017c0 sp 0x7fff5bc00f30 T0)
#0 0x1523fe4c5 in wrap_strcmp.part.6
(/opt/gcc/gcc7a/lib/libasan.4.dylib+0x2d4c5)
#1 0x10079f093 in gfc_get_derived_type(gfc_symbol*, int)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10079f093)
#2 0x1007a45f7 in gfc_typenode_for_spec(gfc_typespec*, int)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1007a45f7)
#3 0x1007a5c9c in gfc_sym_type(gfc_symbol*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1007a5c9c)
#4 0x10079cf37 in gfc_get_function_type(gfc_symbol*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10079cf37)
#5 0x10079d2f7 in gfc_get_ppc_type(gfc_component*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10079d2f7)
#6 0x1007a041d in gfc_get_derived_type(gfc_symbol*, int)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1007a041d)
#7 0x10079fd80 in gfc_get_derived_type(gfc_symbol*, int)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10079fd80)
#8 0x1007a45f7 in gfc_typenode_for_spec(gfc_typespec*, int)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1007a45f7)
#9 0x1007a5c9c in gfc_sym_type(gfc_symbol*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1007a5c9c)
#10 0x10079cf37 in gfc_get_function_type(gfc_symbol*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10079cf37)
#11 0x10079d2f7 in gfc_get_ppc_type(gfc_component*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10079d2f7)
#12 0x1007a041d in gfc_get_derived_type(gfc_symbol*, int)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1007a041d)
#13 0x10079fd80 in gfc_get_derived_type(gfc_symbol*, int)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10079fd80)
#14 0x1007a45f7 in gfc_typenode_for_spec(gfc_typespec*, int)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1007a45f7)
#15 0x1007a5c9c in gfc_sym_type(gfc_symbol*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1007a5c9c)
#16 0x10079cf37 in gfc_get_function_type(gfc_symbol*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10079cf37)
#17 0x10079d2f7 in gfc_get_ppc_type(gfc_component*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10079d2f7)
#18 0x1007a041d in gfc_get_derived_type(gfc_symbol*, int)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1007a041d)
#19 0x10079fd80 in gfc_get_derived_type(gfc_symbol*, int)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10079fd80)
#20 0x1007a45f7 in gfc_typenode_for_spec(gfc_typespec*, int)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1007a45f7)
#21 0x1007a5c9c in gfc_sym_type(gfc_symbol*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1007a5c9c)
#22 0x10079cf37 in gfc_get_function_type(gfc_symbol*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10079cf37)
#23 0x10079d2f7 in gfc_get_ppc_type(gfc_component*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10079d2f7)
#24 0x1007a041d in gfc_get_derived_type(gfc_symbol*, int)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1007a041d)
#25 0x10079fd80 in gfc_get_derived_type(gfc_symbol*, int)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10079fd80)
#26 0x1007a45f7 in gfc_typenode_for_spec(gfc_typespec*, int)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1007a45f7)
#27 0x1007a5c9c in gfc_sym_type(gfc_symbol*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1007a5c9c)
#28 0x10079cf37 in gfc_get_function_type(gfc_symbol*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10079cf37)
#29 0x10079d2f7 in gfc_get_ppc_type(gfc_component*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10079d2f7)
#30 0x1007a041d in 

[Bug rtl-optimization/80385] [5/6 Regression] Segfault in commutative_operand_precedence() rtlanal.c:3373

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] Segfault |[5/6 Regression] Segfault
   |in  |in
   |commutative_operand_precede |commutative_operand_precede
   |nce() rtlanal.c:3373|nce() rtlanal.c:3373

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

[Bug libgomp/80394] Empty OpenMP task is wrongly removed when optimizing

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far, backports queued. Thanks for the report.

[Bug middle-end/80100] simplify-rtx.c sanitizer detects undefined behaviour with optimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/80100] simplify-rtx.c sanitizer detects undefined behaviour with optimization

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 11 17:21:51 2017
New Revision: 246851

URL: https://gcc.gnu.org/viewcvs?rev=246851=gcc=rev
Log:
PR middle-end/80100
* simplify-rtx.c (simplify_binary_operation_1) : Perform
left shift in unsigned HOST_WIDE_INT type.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr80100.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/80385] [5/6/7 Regression] Segfault in commutative_operand_precedence() rtlanal.c:3373

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 11 17:19:56 2017
New Revision: 246850

URL: https://gcc.gnu.org/viewcvs?rev=246850=gcc=rev
Log:
PR rtl-optimization/80385
* simplify-rtx.c (simplify_unary_operation_1): Don't transform
(not (neg X)) into (plus X -1) for complex or non-integral modes.

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

Added:
trunk/gcc/testsuite/g++.dg/opt/pr80385.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog

[Bug libgomp/80394] Empty OpenMP task is wrongly removed when optimizing

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 11 17:15:47 2017
New Revision: 246849

URL: https://gcc.gnu.org/viewcvs?rev=246849=gcc=rev
Log:
PR libgomp/80394
* omp-low.c (scan_omp_task): Don't optimize away empty tasks
if they have any depend clauses.

* testsuite/libgomp.c/pr80394.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/pr80394.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/libgomp/ChangeLog

[Bug rtl-optimization/80352] Improper reload of operands with equiv pseudo

[vmakarov at gcc dot gnu.org]

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

--- Comment #1 from Vladimir Makarov  ---
Thomas, it seems from your description the problem really exists.  I tried to
reproduce the problem with the test you provided but I've failed.  I used 
today trunk.

Could you provide more info (may be -mcpu/-march etc) or/and another test.

[Bug tree-optimization/80397] New: missing -Wformat-overflow with arguments of enum types

[msebor at gcc dot gnu.org]

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

Bug ID: 80397
   Summary: missing -Wformat-overflow with arguments of enum types
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC issues a warning for the buffer overflow in the call to sprintf in function
f in the test case below but it fails to do the same thing for the equivalent
function g.  This is because the format_integer function that extracts the
range of the integral argument tests for the argument's type being INTEGER_TYPE
rather than using the INTEGRAL_TYPE_P() macro as it should be.

$ cat z.c && gcc -O2 -S -Wall -Wextra -Wpedantic z.c
char d[1];

enum E { e10 = 10, e99 = 99 };

int f (int i)
{
  if (i < e10 || e99 < i)
i = e10;

  return __builtin_sprintf (d, "%i", i);   // warning (ok)
}

int g (enum E i)
{
  if (i < e10 || e99 < i)
i = e10;

  return __builtin_sprintf (d, "%i", i);   // missing warning (bug)
}
z.c: In function ‘f’:
z.c:10:33: warning: ‘%i’ directive writing 2 bytes into a region of size 1
[-Wformat-overflow=]
   return __builtin_sprintf (d, "%i", i);   // warning (ok)
 ^~
z.c:10:32: note: directive argument in the range [10, 99]
   return __builtin_sprintf (d, "%i", i);   // warning (ok)
^~~~
z.c:10:10: note: ‘__builtin_sprintf’ output 3 bytes into a destination of size
1
   return __builtin_sprintf (d, "%i", i);   // warning (ok)
  ^~

[Bug ipa/80212] [5/6 Regression] ICE: error: comdat-local function called by virtual

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[5/6/7 Regression] ICE: |[5/6 Regression] ICE:
   |error: comdat-local |error: comdat-local
   |function called by virtual  |function called by virtual
  Known to fail|7.0 |

--- Comment #6 from Martin Liška  ---
Hopefully fixed on trunk without a fall-out.

[Bug ipa/80212] [5/6/7 Regression] ICE: error: comdat-local function called by virtual

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Tue Apr 11 16:38:19 2017
New Revision: 246848

URL: https://gcc.gnu.org/viewcvs?rev=246848=gcc=rev
Log:
Add function part to a same comdat group (PR ipa/80212).

2017-04-11  Martin Liska  

PR ipa/80212
* cgraph.c (cgraph_node::dump): Dump calls_comdat_local.
* ipa-split.c (split_function): Create a local comdat symbol
if caller is in a comdat group.
2017-04-11  Martin Liska  

PR ipa/80212
* g++.dg/ipa/pr80212.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ipa/pr80212.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/ipa-split.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/80364] [7 Regression]sanitizer detects signed integer overflow in gimple-ssa-sprintf.c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Fixed in r246846.

[Bug ipa/80212] [5/6/7 Regression] ICE: error: comdat-local function called by virtual

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Tue Apr 11 16:37:31 2017
New Revision: 246847

URL: https://gcc.gnu.org/viewcvs?rev=246847=gcc=rev
Log:
Do not create a constprop clone for calls_comdat_local nodes (PR ipa/80212).

2017-04-11  Martin Liska  

PR ipa/80212
* ipa-cp.c (determine_versionability): Handle calls_comdat_local
flags.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c

[Bug middle-end/80364] [7 Regression]sanitizer detects signed integer overflow in gimple-ssa-sprintf.c

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Tue Apr 11 16:35:34 2017
New Revision: 246846

URL: https://gcc.gnu.org/viewcvs?rev=246846=gcc=rev
Log:
PR middle-end/80364 - sanitizer detects signed integer overflow in
gimple-ssa-sprintf.c

gcc/ChangeLog:
PR middle-end/80364
* gimple-ssa-sprintf.c (get_int_range): Remove second argument and
always use the int type.  Use INTEGRAL_TYPE_P() rather than testing
for INTEGER_TYPE.
(directive::set_width, directive::set_precision, format_character):
Adjust.
(parse_directive): Use INTEGRAL_TYPE_P() rather than testing for
INTEGER_TYPE.

gcc/testsuite/ChangeLog:
PR middle-end/80364
* gcc.dg/tree-ssa/builtin-sprintf-warn-16.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-16.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog

[Bug target/80381] AVX512: -O3, _mm512_srai_epi32, the last argument must be an 8-bit immediate

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
I was looking at generated code (with -mtune=intel):

vpbroadcastd%edi, %zmm0 # 9 *avx512f_vec_dup_gprv16si/2
[length = 6]
movl%edi, %edi  # 12*zero_extendsidi2/4 [length = 2]
vmovq   %rdi, %xmm1 # 26*movdi_internal/20  [length = 6]
vpsrad  %xmm1, %zmm0, %zmm0 # 17ashrv16si3/1[length = 6]
ret # 29simple_return_internal  [length = 1]

(insn 12) and (insn 26) could be merged to

vmovd   %edx, %xmm0 # 13*zero_extendsidi2/10[length = 6]

Register allocator somehow avoids zero-extension to SSE reg in (insn 12) and
generates input reload (insn 26) for (insn 17):

Inserting insn reload before:
   26: r107:DI=r103:DI
 ...
 Choosing alt 19 in insn 26:  (0) ?*Yi  (1) r {*movdi_internal}

RA could choose the same (?*Yi, r) alternative in the (insn 12).

REE pass also doesn't merge (insn 12) and (insn 26).

[Bug target/80082] [5/6 regression] GCC incorrectly assumes Cortex-r[578] have 64-bit single-copy atomic LDRD

[thopre01 at gcc dot gnu.org]

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

--- Comment #11 from Thomas Preud'homme  ---
Author: thopre01
Date: Tue Apr 11 15:26:20 2017
New Revision: 246844

URL: https://gcc.gnu.org/viewcvs?rev=246844=gcc=rev
Log:
Fix PR80082: LDRD erronously used for 64bit load on ARMv7-R

2017-04-11  Thomas Preud'homme  

Backport from GCC 6
2017-04-06  Thomas Preud'homme  

gcc/
PR target/80082
* config/arm/arm-protos.h (FL_LPAE): Define macro.
(FL_FOR_ARCH7VE): Add FL_LPAE.
(arm_arch_lpae): Declare extern.
* config/arm/arm.c (arm_arch_lpae): Declare.
(arm_option_override): Define arm_arch_lpae.
* config/arm/arm.h (TARGET_HAVE_LPAE): Redefine in term of
arm_arch_lpae.

gcc/testsuite/
PR target/80082
* gcc.target/arm/atomic_loaddi_10.c: New testcase.
* gcc.target/arm/atomic_loaddi_11.c: Likewise.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_10.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_11.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/arm/arm-protos.h
branches/gcc-5-branch/gcc/config/arm/arm.c
branches/gcc-5-branch/gcc/config/arm/arm.h
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c/80354] Poor support to silence -Wformat-truncation=1

[sbergman at redhat dot com]

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

--- Comment #5 from Stephan Bergmann  ---
(In reply to Martin Sebor from comment #3)
> The warning does just what it's designed to do: point out the potential
> unhandled truncation.

But it is unusable in practice if there is no reliable way to silence false
positives.

> If the argument values are such that the truncation
> cannot occur then using snprintf is unnecessary and sprintf can be used
> instead.  Otherwise, if there is a combination of argument values that can
> result in truncation a warning is issued.  Note that the length of output
> produced by each directive can be constrained by specifying a precision for
> %s (e.g., "%.24s" if arena->m_name in the LibreOffice code cannot be longer
> than 24 characters), or by asserting that an integer argument is in some
> limited range of its type (or by using a narrower type to store it).

None of that applies in the case I mentioned, where an at-most 31-character
prefix of "%s_%lu" shall be produced, where the %s argument is known to be a
string of 0..31 characters and the %lu argument is an effectively unconstrained
value of type unsigned long.

> Like all warnings that depend on data flow analysis it is subject to false
> positives but there is no evidence to suggest that on balance it's unhelpful
> or difficult to use.  Quite the contrary.

One cannot even silence the warning locally with a #pragma GCC diagnostic
push/ignored "-Wformat-truncation"/pop just around that call to snprintf:  The
warning is reported on the first line of the function definition containing the
call (see below), and the pragma is only effective if the push/ignored
"-Wformat-truncation" part precedes that first line of the whole function
definition.

> /data/sbergman/lo-gcc/core/sal/rtl/alloc_arena.cxx: In function 
> ‘rtl_arena_type* {anonymous}::rtl_arena_activate(rtl_arena_type*, const 
> char*, sal_Size, sal_Size, rtl_arena_type*, void* (*)(rtl_arena_type*, 
> sal_Size*), void (*)(rtl_arena_type*, void*, sal_Size))’:
> /data/sbergman/lo-gcc/core/sal/rtl/alloc_arena.cxx:672:1: error: ‘%lu’ 
> directive output may be truncated writing between 1 and 20 bytes into a 
> region of size between 0 and 31 [-Werror=format-truncation=]
>  rtl_arena_activate (
>  ^~
> /data/sbergman/lo-gcc/core/sal/rtl/alloc_arena.cxx:717:17: note: ‘snprintf’ 
> output between 3 and 53 bytes into a destination of size 32
>  (void) snprintf (namebuf, sizeof(namebuf), "%s_%" 
> SAL_PRIuUINTPTR, arena->m_name, size);
>  
> ^~~

[Bug target/80389] [7 Regression][ARM] -march=armv8-a and -mcpu=cortex-a57 results in invalid .cpu assembly directive

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Earnshaw  ---
Fixed

[Bug target/80389] [7 Regression][ARM] -march=armv8-a and -mcpu=cortex-a57 results in invalid .cpu assembly directive

[rearnsha at gcc dot gnu.org]

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

--- Comment #5 from Richard Earnshaw  ---
Author: rearnsha
Date: Tue Apr 11 14:57:41 2017
New Revision: 246843

URL: https://gcc.gnu.org/viewcvs?rev=246843=gcc=rev
Log:
[arm] PR 80389 - if architecture and cpu mismatch, don't print an architecture
name as a CPU name

In this PR we incorrectly print the architecture name in a .cpu
directive in the assembly file when the -mcpu and -march options
conflict (don't target the same base architecture).  In this case the
.arch overrides the .cpu directive and we should emit a .arch option.

PR target/80389
* config/arm/arm.c (arm_configure_build_target): When -mcpu and -arch conflict,
set target->arch_name instead of target->cpu_name.

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

[Bug target/80389] [7 Regression][ARM] -march=armv8-a and -mcpu=cortex-a57 results in invalid .cpu assembly directive

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Earnshaw  ---
testing patch.

[Bug c++/80387] [6/7 Regression] G++ get stuck due to decltype over constexpr static function in using declaration

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Markus Trippelsdorf  ---
(In reply to Jonathan Wakely from comment #6)
> This code isn't strictly ice-on-invalid, it's just completely crazy and no
> compiler will ever handle it, because it asks for std::index_sequence<0, 1,
> 2, 3, ..., 18446744073709551614>.
> 
> We could add a static_assert( N != size_t(-1), "" ) but that wouldn't help
> for equally crazy cases like make_index_sequence. Maybe we
> should just reject anything over ULONG_MAX/2.

Lets just call it a pilot error and close it as invalid.

[Bug middle-end/80100] simplify-rtx.c sanitizer detects undefined behaviour with optimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 41177
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41177=edit
gcc7-pr80100.patch

Untested fix.

[Bug c++/80387] [6/7 Regression] G++ get stuck due to decltype over constexpr static function in using declaration

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
This code isn't strictly ice-on-invalid, it's just completely crazy and no
compiler will ever handle it, because it asks for std::index_sequence<0, 1, 2,
3, ..., 18446744073709551614>.

We could add a static_assert( N != size_t(-1), "" ) but that wouldn't help for
equally crazy cases like make_index_sequence. Maybe we should just
reject anything over ULONG_MAX/2.

[Bug target/80389] [7 Regression][ARM] -march=armv8-a and -mcpu=cortex-a57 results in invalid .cpu assembly directive

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
So, if there is a conflict between options, the backend should choose after
warning the more important from those unless it wants to error, and then
continue, so either change -march=armv8-a to something else, or change
-mcpu=cortex-a57 to something else (or ignore).

[Bug target/80389] [7 Regression][ARM] -march=armv8-a and -mcpu=cortex-a57 results in invalid .cpu assembly directive

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Priority|P1  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-11
 Ever confirmed|0   |1

--- Comment #2 from Richard Earnshaw  ---
cc1: warning: switch -mcpu=cortex-a53 conflicts with -march=armv8-a switch

Changing the architecture to -march=armv8-a+crc (which matches cortex-a53)
causes the problem to go away.

[Bug c++/80387] [6/7 Regression] G++ get stuck due to decltype over constexpr static function in using declaration

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
PR 80396 requests such a builtin.

[Bug c++/80396] New: New builtin to make std::make_integer_sequence efficient and scalable

[redi at gcc dot gnu.org]

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

Bug ID: 80396
   Summary: New builtin to make std::make_integer_sequence
efficient and scalable
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Clang has a builtin used for implementing std::make_integer_sequence, so it
scales to much larger sequences than libstdc++'s pure C++ implementation.

The builtin seems to be undocumented, but behaves as though it is an alias
template of the form:

template