[Bug target/89073] x86 __attribute__ ((target("sha"))) not documented

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
It is documented.
https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/x86-Options.html#x86-Options
documents
-msha
and says:
These switches enable the use of instructions in the ... , SHA, ...
instruction sets. Each has a corresponding -mno- option to disable use of these
instructions. 

All the ISA selection options without -m are accepted in target, there are
dozens of options not listed in the spot you are referring.

[Bug tree-optimization/88739] [7/8/9 Regression] Big-endian union bug

[rguenth at gcc dot gnu.org]

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

--- Comment #52 from Richard Biener  ---
Author: rguenth
Date: Mon Jan 28 08:15:42 2019
New Revision: 268332

URL: https://gcc.gnu.org/viewcvs?rev=268332&root=gcc&view=rev
Log:
2019-01-28  Richard Biener  

PR tree-optimization/88739
* tree-cfg.c (verify_types_in_gimple_reference): Verify
BIT_FIELD_REFs only are applied to mode-precision operands
when they are integral.
(verify_gimple_assign_ternary): Likewise for BIT_INSERT_EXPR.
* tree-ssa-sccvn.c (vn_reference_lookup_3): Avoid generating
BIT_FIELD_REFs of non-mode-precision integral operands.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-cfg.c
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/88739] [7/8 Regression] Big-endian union bug

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[7/8/9 Regression]  |[7/8 Regression] Big-endian
   |Big-endian union bug|union bug
  Known to fail|9.0 |

--- Comment #53 from Richard Biener  ---
Fixed on trunk sofar, still waiting for somebody to produce a testcase for the
testsuite (I can't run-test on BE).

[Bug c++/89085] New: call of overload is ambiguous with parameter packs

[lumosimann at gmail dot com]

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

Bug ID: 89085
   Summary: call of overload is ambiguous with parameter packs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lumosimann at gmail dot com
  Target Milestone: ---

The following example behaves differently for GCC and Clang and I am almost
sure that Clang is right, because the second overload is clearly more
specialized:

template 
int a(T const&, Args&&...) {
return 0;
}

template 
int a(int const&, Args&&...) {
return 1;
}

int main() { a<1>(3, 1); }

See https://godbolt.org/z/7eRGmW

Note that the issue requires that

1. parts of the function template needs to be specialized when calling
(removing the first template parameter resolved the problem)

2. it requires a parameter pack


Just some further notes:

- When I add another Arg to the first overload (see
https://godbolt.org/z/AF7TeC), gcc compiles and chooses the first overload, and
clang rejects, and again I think that clang is right
- One way how we can do a workaround: https://godbolt.org/z/WmKdL5

[Bug fortran/89086] New: Add a Fortran language reference chapter

[tkoenig at gcc dot gnu.org]

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

Bug ID: 89086
   Summary: Add a Fortran language reference chapter
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

A big project, not a high priority, but nice to have nontheless:

We should add a Fortran language reference to the documentaiton.

[Bug target/89057] [8/9 Regression] AArch64 ld3 st4 less optimized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |8.3

[Bug testsuite/89064] [9 regression] libgomp.graphite/force-parallel-5.c fails starting with r268257

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Hmm, I had to XFAIL this on the branch but didn't see the FAIL on trunk.  Now
it's there.  Thus, XFAILed there as well.

[Bug testsuite/89064] [9 regression] libgomp.graphite/force-parallel-5.c fails starting with r268257

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Mon Jan 28 09:07:30 2019
New Revision: 268333

URL: https://gcc.gnu.org/viewcvs?rev=268333&root=gcc&view=rev
Log:
2019-01-28  Richard Biener  

PR testsuite/89064
PR tree-optimization/86865
* testsuite/libgomp.graphite/force-parallel-5.c: XFAIL.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.graphite/force-parallel-5.c

[Bug tree-optimization/86865] [9 Regression] Wrong code w/ -O2 -floop-parallelize-all -fstack-reuse=none -fwrapv -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-loop-ivcanon

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Mon Jan 28 09:07:30 2019
New Revision: 268333

URL: https://gcc.gnu.org/viewcvs?rev=268333&root=gcc&view=rev
Log:
2019-01-28  Richard Biener  

PR testsuite/89064
PR tree-optimization/86865
* testsuite/libgomp.graphite/force-parallel-5.c: XFAIL.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.graphite/force-parallel-5.c

[Bug c/89072] -Wall -Werror should be defaults

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

[Bug c++/89087] New: Dllexport for explicit template instantiation with nested classes loses nested class

[martin at martin dot st]

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

Bug ID: 89087
   Summary: Dllexport for explicit template instantiation with
nested classes loses nested class
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin at martin dot st
  Target Milestone: ---

Created attachment 45537
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45537&action=edit
Sample code showing the issue

When an explicit template instantiation of a template class with a nested class
is declared with the dllexport attribute, only members from the outer class
actually gets the embedded export directive.

A caller that sees the explicit template instantiation declaration won't emit
those symbols but produce undefined references to them (both for the outer and
inner class), relying on the template instantiation in a different translation
unit.

If relying on the dllexport attribute for exporting the relevant symbols, only
the outer class' members are exported, and linking to the dll fais.


To showcase the problem:

header.h:
template  struct outer {
  void f();
  struct inner {
void f();
  };
};

template  void outer::f() {}
template  void outer::inner::f() {}

extern template class
#ifdef DLLEXPORT
__declspec(dllexport)
#elif defined(DLLIMPORT)
__declspec(dllimport)
#endif
outer;


lib.cpp:
#define DLLEXPORT
#include "header.h"

template class outer;

caller.cpp:
#define DLLIMPORT
#include "header.h"

int main(int argc, char* argv[]) {
  outer a;
  a.f();
  outer::inner b;
  b.f();
  return 0;
}


Building this fails in this way:
$ make
x86_64-w64-mingw32-g++-c -o caller.o caller.cpp
x86_64-w64-mingw32-g++-c -o lib.o lib.cpp
x86_64-w64-mingw32-g++ -shared -o lib.dll lib.o -Wl,--out-implib,liblib.dll.a
x86_64-w64-mingw32-g++ -o caller.exe caller.o -L. -llib
caller.o:caller.cpp:(.text+0x28): undefined reference to
`outer::inner::f()'
collect2: error: ld returned 1 exit status
Makefile:5: recipe for target 'caller.exe' failed
make: *** [caller.exe] Error 1


The template instantiation in lib.cpp does get both outer and inner function
definitions:
$ x86_64-w64-mingw32-nm lib.o

 T _ZN5outerIcE1fEv
 T _ZN5outerIcE5inner1fEv

And the caller gets undefined references to the same:
$ x86_64-w64-mingw32-nm caller.o 

 T main
 U _ZN5outerIcE1fEv
 U _ZN5outerIcE5inner1fEv

But only the outer function actually ended up exported from the DLL:
$ x86_64-w64-mingw32-objdump -s lib.o

Contents of section .drectve:
  202d6578 706f7274 3a225f5a 4e356f75   -export:"_ZN5ou
 0010 74657249 63453166 45762200   terIcE1fEv".


If the DLL is linked with -Wl,--export-all-symbols, both functions are exported
from the DLL and linking succeeds.


This is contrary to MSVC (which admittedly has got an entirely different C++
ABI). In MSVC, the caller emits the inner class' methods despite the explicit
template instantiation (both when the template instantiation was marked
dllimport, but also if dllimport is omitted):

With dllimport:
$ cl -nologo -c caller.cpp 
caller.cpp
$ x86_64-w64-mingw32-nm caller.obj 

 T ?f@inner@?$outer@D@@QEAAXXZ
 U __imp_?f@?$outer@D@@QEAAXXZ
 T main

Without dllimport:
$ cat caller.cpp | sed 's/^#def.*//' > caller-nodllimport.cpp
$ ~/msvc2017/bin64/cl -nologo -c caller-nodllimport.cpp 
caller-nodllimport.cpp
$ x86_64-w64-mingw32-nm caller-nodllimport.obj 

 T ?f@inner@?$outer@D@@QEAAXXZ
 U ?f@?$outer@D@@QEAAXXZ
 T main



To solve this (short of requiring using -Wl,--export-all-symbols on any library
that uses explicit template instantiation with nested classes), the dllexport
either needs to cover the nested class, or an explicit template instantiation
should only be considered to cover the outer class.

[Bug middle-end/89075] error: type variant has different TREE_TYPE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-checking, lto
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-28
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Component|lto |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

Looks like the pointer type was not properly shared since it looks equal
otherwise.  Both are built via

#6  0x01596d76 in build_qualified_type (
type=, type_quals=0)
at /space/rguenther/src/svn/trunk2/gcc/tree.c:6445
#7  0x01592e9b in free_lang_data_in_type (
type=, fld=0x7fffda60)
at /space/rguenther/src/svn/trunk2/gcc/tree.c:5462
#8  0x01595f53 in free_lang_data_in_cgraph (fld=0x7fffda60)
at /space/rguenther/src/svn/trunk2/gcc/tree.c:6179

#6  0x01596d76 in build_qualified_type (
type=, type_quals=0)
at /space/rguenther/src/svn/trunk2/gcc/tree.c:6445
#7  0x01592e9b in free_lang_data_in_type (
type=, fld=0x7fffda60)
at /space/rguenther/src/svn/trunk2/gcc/tree.c:5462
#8  0x01595f53 in free_lang_data_in_cgraph (fld=0x7fffda60)
at /space/rguenther/src/svn/trunk2/gcc/tree.c:6179

but get_qualified_type doesn't find the duplicate becase the type
we're creating the qualified variant off has TYPE_NAME still as TYPE_DECL
while the one on the variant list is fld-ed already with an IDENTIFIER_NODE
because we do

#4  0x01592e9b in free_lang_data_in_type (
type=, fld=0x7fffda60)
at /space/rguenther/src/svn/trunk2/gcc/tree.c:5462
(gdb) l
5457  if (TYPE_READONLY (arg_type) || TYPE_VOLATILE (arg_type))
5458{
5459  int quals = TYPE_QUALS (arg_type)
5460  & ~TYPE_QUAL_CONST
5461  & ~TYPE_QUAL_VOLATILE;
5462  TREE_VALUE (p) = build_qualified_type (arg_type, quals);
5463  free_lang_data_in_type (TREE_VALUE (p), fld);

but arg_type itself is only fld'ed later.

Which means we need to free-lang-data in SCCs?

[Bug debug/89076] gcc/dwarf2out.c:23270:9: warning: duplicated ‘if’ condition

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Fixed.

[Bug debug/89076] gcc/dwarf2out.c:23270:9: warning: duplicated ‘if’ condition

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Mon Jan 28 09:36:50 2019
New Revision: 268334

URL: https://gcc.gnu.org/viewcvs?rev=268334&root=gcc&view=rev
Log:
2019-01-28  Richard Biener  

PR debug/89076
* dwarf2out.c (gen_subprogram_die): Remove leftover from MPX
support removal.

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

[Bug c++/89080] ICE with immediately invoked constexpr lambda

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Build|9.0.0 20190120  |

--- Comment #1 from Richard Biener  ---
Please paste/attach testcases here.

[Bug fortran/63689] -fcheck=array-temps should warn for temporaries during intrinsic assignment

[bardeau at iram dot fr]

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

--- Comment #3 from Sebastien Bardeau  ---
My concern was more about -fcheck=array-temps (runtime) which does not behave
symmetrically to -Warray-temporaries (compilation time).

pr48655 does not plan to modify the verbosity of -Warray-temporaries, just the
related documentation. So -Warray-temporaries remains an imperfect tool for my
needs.

Anyway, I leave my request closed, as I did not enable those options for a
while and I am not able to confirm if their behavior have improved or not, and
which gfortran version is affected.

[Bug target/89081] [x86] suboptimal code generated for condition expression returning negation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-28
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
I think the issue is that before RA we have

(insn 27 26 30 2 (parallel [
(set (reg:DI 86)
(neg:DI (reg/v:DI 84 [ x ])))
(clobber (reg:CC 17 flags))
]) "t.c":2:26 465 {*negdi2_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 30 27 31 2 (set (reg:CCGOC 17 flags)
(compare:CCGOC (reg/v:DI 84 [ x ])
(const_int 0 [0]))) "t.c":2:26 8 {*cmpdi_ccno_1}
 (expr_list:REG_DEAD (reg/v:DI 84 [ x ])
(nil)))
(insn 31 30 18 2 (set (reg:DI 83 [  ])
(if_then_else:DI (lt (reg:CCGOC 17 flags)
(const_int 0 [0]))
(reg:DI 86)
(reg:DI 87))) "t.c":2:26 942 {*movdicc_noc}

which means both negated and original value have to be live.  So the
issue is that cmpelim runs only after reload?  Or that combine doesn't
try to merge the above or we don't have a suitable pattern.

[Bug c++/89083] [9 Regression] ICE in reshape_init_r, at cp/decl.c:6172

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug lto/89084] [9 Regression] ICE in get_partitioning_class, at symtab.c:1892

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |9.0

[Bug target/88856] [8/9 Regression] gfortran producing wrong code with -funroll-loops

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |krebbel at gcc dot 
gnu.org

--- Comment #4 from Andreas Krebbel  ---
I'm able to reproduce the problem now and will try to have a look.

[Bug target/84923] [8 regression] gcc.dg/attr-weakref-1.c failed on aarch64

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #12 from Ramana Radhakrishnan  ---
I don't think this is fixed on GCC-8 as the commit to trunk happened on May 21
18 after the release was made 


Thanks,
Ramana

[Bug target/89073] x86 __attribute__ ((target("sha"))) not documented

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jan 28 10:38:29 2019
New Revision: 268335

URL: https://gcc.gnu.org/viewcvs?rev=268335&root=gcc&view=rev
Log:
PR target/89073
* doc/invoke.texi (-mclwb, -mprfchw, -mrdpid, -mrdseed, -msgx,
-madx, -mhle, -mavx5124fmaps, -mavx512vnni, -mavx5124vnniw): Document
x86 ISA options.
(bmi2): Add missing @opindex.
* doc/extend.texi (x86 target attribute): Move fma4, lwp, ssse3
options alphabetically.  Add missing 3dnow, 3dnowa, adx, avx, avx2,
avx5124fmaps, avx5124vnniw, avx512bitalg, avx512bw, avx512cd,
avx512dq, avx512er, avx512f, avx512ifma, avx512pf, avx512vbmi,
avx512vbmi2, avx512vl, avx512vnni, avx512vpopcntdq, bmi, bmi2,
cldemote, clflushopt, clwb, clzero, crc32, cx16, f16c, fma, fsgsbase,
fxsr, gfni, hle, lzcnt, movbe, movdir64b, movdiri, mwaitx, pconfig,
pku, prefetchwt1, prfchw, ptwrite, rdpid, rdrnd, rdseed, rtm, sahf,
sgx, sha, shstk, tbm, vaes, vpclmulqdq, waitpkg, wbnoinvd, xsave,
xsavec, xsaveopt and xsaves options.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi
trunk/gcc/doc/invoke.texi

[Bug fortran/86312] missing runtime warning for array temporary with -fcheck=array-temps

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Dominique d'Humieres  ---
With a clean revision r268299, there is no warning at run time:

% gfca pr86312.f90 -Warray-temporaries -fcheck=array-temps
pr86312.f90:12:9:

   12 | call sub(ia(1,:))   ! runtime warning: array temporary
  | 1
Warning: Creating array temporary at (1) [-Warray-temporaries]
pr86312.f90:15:9:

   15 | call sub(xx(:)%i)   ! no runtime warning?!?
  | 1
Warning: Creating array temporary at (1) [-Warray-temporaries]
% ./a.out
   1   1   1   1   1   1   
   1   1   1   1
   1   1   1   1   1   1   
   1   1   1   1
   3   3   3   3   3   3   
   3   3   3   3

However if I apply the patch at
https://gcc.gnu.org/ml/fortran/2019-01/msg00223.html
I get

% gfcp pr86312.f90 -Warray-temporaries -fcheck=array-temps
pr86312.f90:12:9:

   12 | call sub(ia(1,:))   ! runtime warning: array temporary
  | 1
Warning: Creating array temporary at (1) [-Warray-temporaries]
pr86312.f90:15:9:

   15 | call sub(xx(:)%i)   ! no runtime warning?!?
  | 1
Warning: Creating array temporary at (1) [-Warray-temporaries]
% ./a.out
At line 12 of file pr86312.f90
Fortran runtime warning: An array temporary was created
   1   1   1   1   1   1   
   1   1   1   1
   1   1   1   1   1   1   
   1   1   1   1
At line 15 of file pr86312.f90
Fortran runtime warning: An array temporary was created
   3   3   3   3   3   3   
   3   3   3   3

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

[Bug fortran/48655] False positive with -Warray-temporaries and a=transpose(a)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #4 from Dominique d'Humieres  ---
*** Bug 86312 has been marked as a duplicate of this bug. ***

[Bug fortran/48655] "False positive" with -Warray-temporaries or missing warning with -fcheck=array-temps

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|False positive with |"False positive" with
   |-Warray-temporaries and |-Warray-temporaries or
   |a=transpose(a)  |missing warning with
   ||-fcheck=array-temps

--- Comment #5 from Dominique d'Humieres  ---
> Well, the front end generates the temporary, but the middle end removes it 
> again.

While looking at pr86312, I realized that this not the case: when the warning
is emitted at run time, the file generated by -fdump-tree-original contains
lines such as:

  _gfortran_runtime_warning_at (&"At line 12 of file pr86312.f90"[1]{lb: 1
sz: 1}, &"An array temporary was created"[1]{lb: 1 sz: 1});

So the question is why such lines are sometime emitted and sometime not.

[Bug target/89073] x86 __attribute__ ((target("sha"))) not documented

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug fortran/48655] "False positive" with -Warray-temporaries or missing warning with -fcheck=array-temps

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
*** Bug 86313 has been marked as a duplicate of this bug. ***

[Bug fortran/86313] make -Warray-temporaries less noisy

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Dominique d'Humieres  ---
Duplicate of pr48655.

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

[Bug fortran/48655] "False positive" with -Warray-temporaries or missing warning with -fcheck=array-temps

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
From pr86313, the test

program p
   integer :: f
   integer, dimension(1:3) :: u
   f = 1
   u = f + (/0, 1, 2/)
   print *, u
end

gives a warning at compile time with -ffrontend-optimize, but not without (no
warning at run time):

% gfca pr86313_2.f90 -Warray-temporaries -fcheck=array-temps
-ffrontend-optimize
pr86313_2.f90:5:7:

5 |u = f + (/0, 1, 2/)
  |   1
Warning: Creating array temporary at (1) [-Warray-temporaries]
% ./a.out
   1   2   3
% gfca pr86313_2.f90 -Warray-temporaries -fcheck=array-temps 
%

[Bug c++/86432] ICE on capture VLA by reference

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #1 from Arseny Solokha  ---
It looks like a duplicate of PR60855 to me.

[Bug c++/79325] [7/8/9 Regression] ICE on valid GNU C++ code (typeof) on x86_64-linux-gnu: in arg_assoc_type, at cp/name-lookup.c:5823

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
This is fixed in 8.1.0.

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

[Bug c++/71820] ICE on valid C++ code: in arg_assoc_type, at cp/name-lookup.c:5583

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  ---
*** Bug 79325 has been marked as a duplicate of this bug. ***

[Bug c++/89088] New: Dllexport for explicit template instantiation missing inline methods

[martin at martin dot st]

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

Bug ID: 89088
   Summary: Dllexport for explicit template instantiation missing
inline methods
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin at martin dot st
  Target Milestone: ---

Created attachment 45538
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45538&action=edit
Sample code showing the issue

With dllexported explicit template instantiation, inline methods aren't
exported, but callers still create undefined references to the inline methods,
which fail due to the missing export. (This can be remedied by applying
-Wl,--export-all-symbols to export all generated symbols, regardless of
dllexport attributes.)

Example:

header.h:
template  struct C {
  void f();
  void g() {}
};

template  void C::f() {}

extern template class
#ifdef DLLEXPORT
__declspec(dllexport)
#elif defined(DLLIMPORT)
__declspec(dllimport)
#endif
C;

lib.cpp:
#define DLLEXPORT
#include "header.h"

template class C;

caller.cpp:
#define DLLIMPORT
#include "header.h"

int main(int argc, char* argv[]) {
  C a;
  a.g();
  return 0;
}

Building of this fails in this way:
$ make
x86_64-w64-mingw32-g++-c -o caller.o caller.cpp
x86_64-w64-mingw32-g++-c -o lib.o lib.cpp
x86_64-w64-mingw32-g++ -shared -o lib.dll lib.o -Wl,--out-implib,liblib.dll.a
x86_64-w64-mingw32-g++ -o caller.exe caller.o -L. -llib
caller.o:caller.cpp:(.text+0x1c): undefined reference to `C::g()'
collect2: error: ld returned 1 exit status
Makefile:5: recipe for target 'caller.exe' failed
make: *** [caller.exe] Error 1


The instantiation definition in lib.cpp emitted both methods, but only export
the non-inline method:
$ x86_64-w64-mingw32-nm lib.o 

 T _ZN1CIcE1fEv
 T _ZN1CIcE1gEv
$ x86_64-w64-mingw32-objdump -s lib.o

Contents of section .drectve:
  202d6578 706f7274 3a225f5a 4e314349   -export:"_ZN1CI
 0010 63453166 45762200cE1fEv".

However, despite this, the caller creates an undefined reference to the inline
method:
$ x86_64-w64-mingw32-nm caller.o 

 T main
 U _ZN1CIcE1gEv

[Bug c++/89089] New: [9 regression] various ICEs in range-v3's 1.0 branch

[h2+bugs at fsfe dot org]

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

Bug ID: 89089
   Summary: [9 regression] various ICEs in range-v3's 1.0 branch
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h2+bugs at fsfe dot org
  Target Milestone: ---

The 1.0-beta branch of the range-v3 library triggers various (seemingly
different) ICEs in GCC9. GCC7 and GCC8 seem not affected. This is even without
-std=c++2a or -fconcepts.

% g++9 --version
g++9 (FreeBSD Ports Collection) 9.0.0 20190113 (experimental)

Here are the reports: https://github.com/ericniebler/range-v3/issues/1011

I can provide intermediate files in this PR, but it would probably be good to
just pull the above branch and build the test suite since that might reveal
more issues?

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-01-28
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Please do provide preprocessed sources and g++ command line options needed to
trigger it.

[Bug libstdc++/89090] New: vector.tcc uses "if constexpr" in C++11 mode

[csaba_22 at yahoo dot co.uk]

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

Bug ID: 89090
   Summary: vector.tcc uses "if constexpr"  in C++11 mode
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: csaba_22 at yahoo dot co.uk
  Target Milestone: ---

vector.tcc contains the following at line 613
#if __cplusplus >= 201103L
  template
void
vector<_Tp, _Alloc>::
_M_default_append(size_type __n)
{
  if (__n != 0)
{
  const size_type __size = size();
  size_type __navail = size_type(this->_M_impl._M_end_of_storage
 - this->_M_impl._M_finish);

  if (__size > max_size() || __navail > max_size() - __size)
__builtin_unreachable();

  if (__navail >= __n)
{
  _GLIBCXX_ASAN_ANNOTATE_GROW(__n);
  this->_M_impl._M_finish =
std::__uninitialized_default_n_a(this->_M_impl._M_finish,
 __n, _M_get_Tp_allocator());
  _GLIBCXX_ASAN_ANNOTATE_GREW(__n);
}
  else
{
  const size_type __len =
_M_check_len(__n, "vector::_M_default_append");
  pointer __new_start(this->_M_allocate(__len));
#if __cplusplus >= 201103L
  if constexpr (__use_relocate)
{
  __try
{
  std::__uninitialized_default_n_a(__new_start + __size,
  __n, _M_get_Tp_allocator());
}
  __catch(...)
{
  _M_deallocate(__new_start, __len);
  __throw_exception_again;
}
  std::__relocate_a(this->_M_impl._M_start,
this->_M_impl._M_finish,
__new_start, _M_get_Tp_allocator());
}
  else
#endif
{
  pointer __destroy_from = pointer();
  __try
{
  std::__uninitialized_default_n_a(__new_start + __size,
  __n, _M_get_Tp_allocator());
  __destroy_from = __new_start + __size;
  std::__uninitialized_move_if_noexcept_a(
  this->_M_impl._M_start, this->_M_impl._M_finish,
  __new_start, _M_get_Tp_allocator());
}
  __catch(...)
{
  if (__destroy_from)
std::_Destroy(__destroy_from, __destroy_from + __n,
  _M_get_Tp_allocator());
  _M_deallocate(__new_start, __len);
  __throw_exception_again;
}
  std::_Destroy(this->_M_impl._M_start,
this->_M_impl._M_finish,
_M_get_Tp_allocator());
}
  _GLIBCXX_ASAN_ANNOTATE_REINIT;
  _M_deallocate(this->_M_impl._M_start,
this->_M_impl._M_end_of_storage
- this->_M_impl._M_start);
  this->_M_impl._M_start = __new_start;
  this->_M_impl._M_finish = __new_start + __size + __n;
  this->_M_impl._M_end_of_storage = __new_start + __len;
}
}
}

The two nested "#if __cplusplus >= 201103L" checks are suspicious (copy-paste
error?)
Generating preprocessor output from a one-liner of #include  with
-std=c++11 -save-temps results in a .ii file which shouldn't even compile in
C++11 mode.

[Bug tree-optimization/89027] [9 Regression] ICE: verify_gimple failed (Error: non-trivial conversion at assignment)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug preprocessor/88974] [9 Regression] ICE: Segmentation fault (in linemap_resolve_location)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[h2+bugs at fsfe dot org]

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

--- Comment #2 from Hannes Hauswedell  ---
Created attachment 45539
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45539&action=edit
first ICE

Build with:
g++9 -std=c++17 -fconcepts -Wall -Wextra variant.cpp

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[h2+bugs at fsfe dot org]

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

--- Comment #3 from Hannes Hauswedell  ---
Created attachment 45540
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45540&action=edit
second ICE

g++9 -std=c++17 -fconcepts -Wall -Wextra concat.cpp

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[h2+bugs at fsfe dot org]

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

--- Comment #4 from Hannes Hauswedell  ---
Created attachment 45541
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45541&action=edit
third ICE

g++9 -std=c++17 -fconcepts -Wall -Wextra take_while.cpp

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[h2+bugs at fsfe dot org]

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

--- Comment #5 from Hannes Hauswedell  ---
PS: I do have to correct myself: since range-v3 now auto-detects concept
support the tests are indeed built with -fconcepts.

[Bug libstdc++/89090] vector.tcc uses "if constexpr" in C++11 mode

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-28
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug c++/89083] [9 Regression] ICE in reshape_init_r, at cp/decl.c:6172

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-28
 CC||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c++/89083] [9 Regression] ICE in reshape_init_r, at cp/decl.c:6172

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
The #c2 and #c3 preprocessed sources started ICEing in r261084, first like:
internal compiler error: in tsubst_copy, at cp/pt.c:15935
0xa3de70 tsubst_copy
../../gcc/cp/pt.c:15935
0xa502ec tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18994
0xa35c66 tsubst_exception_specification
../../gcc/cp/pt.c:14103
0xa61be7 regenerate_decl_from_template
../../gcc/cp/pt.c:23353
0xa65370 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:23921
and then #c2 in r267155 changed into:
internal compiler error: Segmentation fault
0x13abb3c crash_signal
../../gcc/toplev.c:326
0x82a599 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3270
0xeb0d33 size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc/fold-const.c:1905
0x8782a8 end_of_class
../../gcc/cp/class.c:5962
0x878c07 layout_class_type
../../gcc/cp/class.c:6162
0x87c429 finish_struct_1(tree_node*)
../../gcc/cp/class.c:6941
0xa7f5f4 instantiate_class_template_1
../../gcc/cp/pt.c:11393
0xa7f76a instantiate_class_template(tree_node*)
../../gcc/cp/pt.c:11432
0xb47f8d complete_type(tree_node*)
../../gcc/cp/typeck.c:138
0xb47fb2 complete_type_or_maybe_complain(tree_node*, tree_node*, int)
../../gcc/cp/typeck.c:150
0xb47c09 require_complete_type_sfinae(tree_node*, int)
../../gcc/cp/typeck.c:94
#c3 similarly, but already in r264813.
#c4 never ICEd in tsubst_copy, only started to ICE with r264813.

[Bug c/89045] [9 Regression] ICE in get_parm_info, at c/c-decl.c:7518

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 45542
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45542&action=edit
gcc9-pr89045.patch

Untested fix.

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Reduced testcase from #c2, doesn't really need -fconcepts, ICEs also with just
-std=c++17.  Doesn't ICE without no_unique_address, G++ 8 ignores that
attribute with a warning.
template  struct A {};
template  struct A {
private:
  [[no_unique_address]] A a;
};
struct B {
  template  A operator()(U...) { return A(); }
} f;
auto fn = f (int{}, [] {});

[Bug rtl-optimization/88593] [9 Regression] cleanup_cfg may make cached dominance info stale

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
And isn't it latent on all older branches too?  Or do you have revision number
between 8 and 9 that broke this?

[Bug target/88100] no warning reported when value for vec_splat_{su}{8,16} would overflow

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #3 from Bill Schmidt  ---
None of these should be getting warning messages at all; they should all be
getting error messages because the input literals are out of range!  These are
documented as requiring a signed 5-bit literal as input.

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/89083] [9 Regression] ICE in reshape_init_r, at cp/decl.c:6172

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
I think the fix will be same as for PR80864, maybe along the lines of not
reshaping an already reshaped init.  I think r268321 more of less uncovered a
latent problem.

[Bug libfortran/89020] close(status='DELETE') does not remove file

[robison at arlut dot utexas.edu]

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

--- Comment #17 from Luke Robison  ---
(In reply to Jerry DeLisle from comment #8)

> Luke, do you ever build gcc?

I applied these patches to 8.2.0 and got the expected error message and iostat
of 26.  Looks good to me.  Thanks.

[Bug middle-end/89091] New: ICE: Segmentation fault (in tree_class_check)

[asolokha at gmx dot com]

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

Bug ID: 89091
   Summary: ICE: Segmentation fault (in tree_class_check)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-9.0.0-alpha20190127 snapshot (r268327), 9.0, 8.2, 7.4, 6.3, 5.4, 4.9.4,
4.8.5, 4.7.4, 4.6.4 all ICE when compiling the following testcase at any
optimization level:

struct b8 {
  unsigned __int128 tv : 65;
};

int
sn (struct b8 *pj, int lp)
{
  return lp && pj->tv;
}

% x86_64-unknown-linux-gnu-gcc-9.0.0-alpha20190127 -O1 -c xmcrisq9.c
xmcrisq9.c: In function 'sn':
xmcrisq9.c:8:3: internal compiler error: Segmentation fault
8 |   return lp && pj->tv;
  |   ^~
0xd7147f crash_signal
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/toplev.c:326
0xa77e95 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/tree.h:3298
0xa77e95 decode_field_reference
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/fold-const.c:4327
0xa843fb fold_truth_andor_1
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/fold-const.c:5903
0xa859e4 fold_truth_andor
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/fold-const.c:8239
0xa69e19 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/fold-const.c:10523
0xa70539 fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/fold-const.c:12350
0x8487ee c_fully_fold_internal
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/c/c-fold.c:535
0x849087 c_fully_fold(tree_node*, bool, bool*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/c/c-fold.c:125
0x7fda7d c_finish_return(unsigned int, tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/c/c-typeck.c:10524
0x83b007 c_parser_statement_after_labels
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/c/c-parser.c:5521
0x83bfea c_parser_compound_statement_nostart
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/c/c-parser.c:5146
0x83c558 c_parser_compound_statement
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/c/c-parser.c:4980
0x83de55 c_parser_declaration_or_fndef
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/c/c-parser.c:2352
0x84520f c_parser_external_declaration
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/c/c-parser.c:1653
0x845c49 c_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/c/c-parser.c:1534
0x845c49 c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/c/c-parser.c:19840
0x89992b c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/c-family/c-opts.c:1155

(g++ ICEs similarly.)

[Bug c++/71548] Invalid declaration involving template template param causes crash

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Arseny Solokha  ---
Is it still an issue on currently supported branches? It seems gcc 6.3 still
ICEs on this testcase while gcc 7.1 and later reject it w/o ICE.

[Bug libstdc++/89090] vector.tcc uses "if constexpr" in C++11 mode

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Csaba Ráduly from comment #0)
> The two nested "#if __cplusplus >= 201103L" checks are suspicious
> (copy-paste error?)
> Generating preprocessor output from a one-liner of #include  with
> -std=c++11 -save-temps results in a .ii file which shouldn't even compile in
> C++11 mode.

But it does compile, because the usage in only in a system header, and gcc
allows that.

Are you actually seeing a problem because of this?

[Bug middle-end/89002] [7/8/9 Regression] ICE in scan_omp_1_op, at omp-low.c:3166

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug middle-end/89091] ICE: Segmentation fault (in tree_class_check)

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-28
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed, at -O1 and above.

Segfaults reading through NULL "unsigned_type" here in decode_field_reference:

4325  /* Compute the mask to access the bitfield.  */
4326  unsigned_type = lang_hooks.types.type_for_size (*pbitsize, 1);
4327  precision = TYPE_PRECISION (unsigned_type);

[Bug c++/89080] ICE with immediately invoked constexpr lambda

[chss95cs at gmail dot com]

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

--- Comment #2 from chss95cs at gmail dot com ---
(In reply to Richard Biener from comment #1)
> Please paste/attach testcases here.

This is the code that caused the ICE. I put it in the URL field:

https://godbolt.org/z/1IOgpU

[Bug c++/89080] ICE with immediately invoked constexpr lambda

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Which is this.  Curiously, I don't see an ICE with -std=c++2a -fconcepts.

#include 


template
struct make_7bit{
static constexpr auto v = s();


static constexpr unsigned required_bytes = ([](){
constexpr unsigned bits = (__builtin_strlen(v) * 7);
constexpr unsigned bits_div = (bits) / 8;
constexpr unsigned bits_rem = bits % 8;
return bits_div + (bits_rem ==0 ?0:1);
})();

static constexpr std::array packed = 
([](){
std::array packed_data{};

unsigned currpos = 0;

auto submit_bit = [&currpos, &packed_data] (unsigned bit){
packed_data[currpos / 8] |= (bit&1) << (currpos%8);
};

auto submit_char = [&submit_bit](char c){
uint8_t cc = (uint8_t)c;

for(unsigned i = 0; i < 7;++i){
submit_bit(cc>>i);
}
};

unsigned l = __builtin_strlen(v);

for(unsigned i = 0; i < l; ++i){
submit_char(v[i]);
}

return packed_data;
})();

};

#define static_string(...)  []()constexpr{return __VA_ARGS__;}

using nowdie = make_7bit;

const uint8_t* kills_compiler() {
return &nowdie::packed[0];
}

[Bug target/89071] AVX vcvtsd2ss lets us avoid PXOR dependency breaking for scalar float<->double and other scalar xmm,xmm instructions

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Depends on||87007

--- Comment #1 from H.J. Lu  ---
vcvtsd2ss   %xmm1, %xmm1, %xmm0

is faster than

vcvtsd2ss   %xmm1, %xmm0, %xmm0

But

vxorps  %xmm0, %xmm0, %xmm0
vcvtsd2ss   %xmm1, %xmm0, %xmm0

are faster than both.  I have a patch for PR 87007:

https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00298.html

which inserts a vxorps at the last possible position.  vxorps
will be executed only once in a function.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87007
[Bug 87007] [8/9 Regression] 10% slowdown with -march=skylake-avx512

[Bug c++/89080] ICE with immediately invoked constexpr lambda

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-28
 Ever confirmed|0   |1

--- Comment #4 from Marek Polacek  ---
Oh it needs -g.

[Bug c++/89080] ICE with immediately invoked constexpr lambda

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #5 from Marek Polacek  ---
Started with r266056.

[Bug fortran/89092] New: Host-associated generic used instead of use-associated TBP in call

[trnka at scm dot com]

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

Bug ID: 89092
   Summary: Host-associated generic used instead of use-associated
TBP in call
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trnka at scm dot com
  Target Milestone: ---

GFortran rejects the following testcase because it only considers the
host-associated generic interface when resolving the call to y%Foo() instead of
the expected type-bound procedure. This dates back to GCC 5 at least.

   call y%Foo()
  1
Error: There is no specific subroutine for the generic ‘foo’ at (1)

According to F2008 16.3.1, this should be valid Fortran, because TBPs belong to
a different class than generic interfaces, so they shouldn't clash. My
understanding of 12.5.6 is that the procedure-designator "Foo" should match the
corresponding specific TBP.

Intel Fortran accepts the testcase and gives the expected behaviour (the TBP is
called, printing "Foo(BType)").

I guess this could be related to PR 54035 or PR 57126, but I can't really tell
for sure.

module AModule
   implicit none
   private
   public Foo

   interface Foo
  module procedure FooPrivate
   end interface
contains
   subroutine FooPrivate(x)
  integer :: x

  write(*,*) 'Foo(integer)'
   end subroutine
end module
module BModule
   implicit none
   private

   type, public :: BType
   contains
  procedure :: Foo
   end type
contains
   subroutine Foo(self)
  class(BType) :: self

  write(*,*) 'Foo(BType)'
   end subroutine
end module
program iface_tbp_test
   use AModule
   implicit none

   call test()

contains
   subroutine test()
  use BModule

  type(BType) :: y

  call y%Foo()
   end subroutine
end program


Everything works as expected if the TBP binding is changed as follows:

   type, public :: BType
   contains
  procedure :: Foo => FooX
   end type
contains
   subroutine FooX(self)
  class(BType) :: self

  write(*,*) 'Foo(BType)'
   end subroutine

[Bug c++/80864] [7/8/9 Regression] Brace-initialization of a constexpr variable of an array in a POD triggers ICE from templates

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Probably the same issue as in 89083 -- which I'm currently assigned to.

[Bug middle-end/89091] ICE: Segmentation fault (in tree_class_check)

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

[Bug fortran/71066] [7/8/9 Regression] ICE in set_loop_bounds, at fortran/trans-array.c:4680

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  ---
On Sun, Jan 27, 2019 at 09:56:48PM +, kargl at gcc dot gnu.org wrote:
> > 
> > The second one appears to be OK.
> 
> The second one is invalid.
> 
> f2008:C565
> A data-stmt-object or data-i-do-object shall not be a coindexed variable.
> 
> f2018:C873
> A data-stmt-object or data-i-do-object shall not be a coindexed variable.
> 

Seems that I misinterpreted the meaning of "coindexed variable".
See Rienhold Bader's reply in c.l.f.

[Bug c++/89093] New: C++ exception handling clobbers d8 VFP register

[fw at gcc dot gnu.org]

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

Bug ID: 89093
   Summary: C++ exception handling clobbers d8 VFP register
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---
Target: armv7l-unknown-linux-gnueabihf

In glibc, we have a test, nptl/tst-thread-exit-clobber, that attempts to verify
if registers are properly restored by unwinding.  (The actual target of the the
test is pthread_exit, but it covers more than that.)

This tests fails when running with GCC 9 libstdc++, even if glibc and the test
were built with GCC 8, and libgcc_s is replaced with the version for GCC 8
(which works when running against GCC 8 libstdc++).

In the test, the d8 register is not restored properly during unwinding, it is
set to zero.  d9, d10 etc. are restored.

I noticed that in GCC 9, __gxx_personality_v0 saves the d8 VFP register:

0007b620 <__gxx_personality_v0@@CXXABI_1.3>:
   7b620:   e92d4ff0push{r4, r5, r6, r7, r8, r9, sl, fp, lr}
   7b624:   ed2d8b02vpush   {d8}
   7b628:   e3a03000mov r3, #0
   7b62c:   e1a08001mov r8, r1

And it actually uses s16 and s17, apparently for spilling integer registers. 
Perhaps the unwinder is not prepared to deal with that.

This happens with gcc version 9.0.0 20190119 (Red Hat 9.0.0-0.3) (GCC), built
with:

--with-tune=generic-armv7-a --with-arch=armv7-a --with-float=hard
--with-fpu=vfpv3-d16 --with-abi=aapcs-linux
--build=armv7hl-redhat-linux-gnueabi

[Bug c++/88358] variable template definition taken as function template declaration with implicit typename

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #5 from Marek Polacek  ---
Ah I see.  Let me fix that.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||8.1.0
   Target Milestone|--- |9.0
Summary|C++ exception handling  |[9 Regression] C++
   |clobbers d8 VFP register|exception handling clobbers
   ||d8 VFP register

--- Comment #1 from Andrew Pinski  ---
According to https://sourceware.org/ml/libc-alpha/2019-01/msg00651.html it
worked in GCC 8.1.0.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
It is indeed saved in the prologue:
@ args = 0, pretend = 0, frame = 64
@ frame_needed = 0, uses_anonymous_args = 0
and ip, r0, #3
push{r4, r5, r6, r7, r8, r9, r10, fp, lr}
.save {r4, r5, r6, r7, r8, r9, r10, fp, lr}
cmp ip, #1
vpush.64{d8}
.vsave {d8}
mov r3, #0
.pad #76
sub sp, sp, #76
but it is restored in the epilogue:
.L61:
add sp, sp, #76
@ sp needed
vldmsp!, {d8}
pop {r4, r5, r6, r7, r8, r9, r10, fp, pc}
and there are no other returns that I can see.  So, why isn't it restored
there?
Has the stack pointer been clobbered, or the stack slot in there?
eh_personality.cc has been compiled with
-mtune=cortex-a9 -mfloat-abi=hard -mfpu=vfpv3-d16 -mtls-dialect=gnu -marm
-march=armv7-a+fp -O2 -fPIC

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Like in https://bugzilla.redhat.com/show_bug.cgi?id=1670069 (another wrong-code
that has been reported to us today), eh_personality.cc (__gxx_personality_v0)
is compiled this way since r266385.  Though, in this case it seems more like a
missed optimization, at least I still fail to understand what is incorrect on
it.

[Bug other/89094] New: collect2.c:main c_argv buffer is undersized when -EL, -EB or -B used in COLLECT_GCC_OPTIONS

[remi at machet dot us]

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

Bug ID: 89094
   Summary: collect2.c:main c_argv buffer is undersized when -EL,
-EB or -B used in COLLECT_GCC_OPTIONS
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: remi at machet dot us
  Target Milestone: ---

collect2.c main() uses an array to store filtered arguments called c_argv. The
size of that array is based on num_c_args which account for 15 entries plus
command line arguments and one entry per -qm or -qf argument inside
COLLECT_GCC_OPTIONS:
/* Now pick up any flags we want early from COLLECT_GCC_OPTIONS
   The LTO options are passed here as are other options that might
   be unsuitable for ld (e.g. -save-temps).  */
p = getenv ("COLLECT_GCC_OPTIONS");
while (p && *p)
  {
const char *q = extract_string (&p);
if (*q == '-' && (q[1] == 'm' || q[1] == 'f'))
  num_c_args++;
...

But later, when the array is filled, more options not accounted for above are
added to the array if found in COLLECT_GCC_OPTIONS: -EL, -EB, -B and 2
entries for '-B ':
  if (*q == '-' && (q[1] == 'm' || q[1] == 'f'))
*c_ptr++ = xstrdup (q);
  if (strcmp (q, "-EL") == 0 || strcmp (q, "-EB") == 0)
*c_ptr++ = xstrdup (q);
  if (strcmp (q, "-shared") == 0)
shared_obj = 1;
  if (strcmp (q, "-static") == 0)
static_obj = 1;
  if (*q == '-' && q[1] == 'B')
{
  *c_ptr++ = xstrdup (q);
  if (q[2] == 0)
{
  q = extract_string (&p);
  *c_ptr++ = xstrdup (q);
}
}

Any of the extra options, if present, is causing c_argv to overflow.

[Bug fortran/85868] Subarray of a pointer array associated with a pointer dummy argument

[anlauf at gmx dot de]

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

--- Comment #6 from Harald Anlauf  ---
Another testcase suitable for debugging is the following, which better
shows correspondence for pre-F2008 and F2008+ variants:

program test
  implicit none
  integer, pointer :: t(:), u(:)
  integer  :: i
  allocate (t(-1:5))
  do i = -1, 5
 t(i) = i
  end do
  call p (t )  ! Pointer with lower bound = -1 from allocation
  u => t   ! Pointer assignment sets same lower bound
  call p (u)
  !
  u => t( :)   ! Pointer assignment with implicit lower bound (1)
  call p (u)
  call p (t(  :))  ! Full array, behaves the same
  !
  call p (t( 0:))  ! Array section
  u => t(0:)   ! Pointer assignment with implicit lower bound (1)
  call p (u)
  u(0:) => t(0:)   ! Pointer assignment with given lower bound (0)
  call p (u)
contains
  subroutine p (a)
integer, pointer, intent(in) :: a(:)
print *, a(1)
  end subroutine p
end program

NAG and Crayftn both print the supposedly correct result:

 1
 1
 -1
 -1
 0
 0
 1

Current 9-trunk:

   1
   1
  -1
   1
   2
   0
   1

gcc-8.2.1:

   1
   1
  -1
   1
   0
   0
   1

gcc-7.3.1, 6.x, 5.x, 4.6:

   1
   1
  -1
   1
   1
   0
   1

gcc-4.9, 4.8:

   1
   1
  -1
   1
   1
   0
   0

So it is a varying sort of wrong code issue...
Only output lines 1,2,3 and 6 are always correct.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[fw at gcc dot gnu.org]

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

--- Comment #4 from Florian Weimer  ---
So I'm not really an Arm person or a GCC person, but doesn't the personality
routine call the landing pad, as identified by the LDSA?  And then that ends
with a call to __cxa_end_cleanup, which is clear a no-return function (I think
other targets call this function _Unwind_Resume).  So the epilogue of the
personality routine never runs.

I doubt the Arm unwinding information covers the the VFP registers, so there is
not much the unwinder can do about this.

[Bug c++/88358] variable template definition taken as function template declaration with implicit typename

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01625.html

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
I admit I don't know much about ARM unwinding, which is different from all the
other arches, but normally the personality routine doesn't call the landing pad
code nor anything similar, it should set some registers in unwind context and
return and through return value and whatever it stores into the unwind context
tell the caller what to do (whether to install the context etc.).

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[fw at gcc dot gnu.org]

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

--- Comment #6 from Florian Weimer  ---
Okay, please assume that __gxx_personality_v0 is a red herring.  Apparently,
there is unwinding information for VFP registers, too.

[Bug fortran/68933] ICE when mixing "-fprofile-arcs -ftest-coverage" and "-fcoarray=lib" on gcc-6 only

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #8 from Dominique d'Humieres  ---
> GCC6 is no longer supported, this PR should probably closed as FIXED.

No feedback, closing.

[Bug fortran/83700] [Meta-bug] Fortran Coarray issues

[dominiq at lps dot ens.fr]

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

Bug 68933 Summary: ICE when mixing "-fprofile-arcs -ftest-coverage" and 
"-fcoarray=lib" on gcc-6 only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933

   What|Removed |Added

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

[Bug testsuite/89095] New: gcc-dg-prune calls check_effective_target_offload_gcn every time

[hjl.tools at gmail dot com]

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

Bug ID: 89095
   Summary: gcc-dg-prune calls check_effective_target_offload_gcn
every time
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ams at gcc dot gnu.org
  Target Milestone: ---

On x86, I am getting:

spawn -ignore SIGHUP
/export/build/gnu/tools-build/gcc-mmx/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-mmx/build-x86_64-linux/gcc/
offload_gcn14246.c -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-foffload=amdgcn-unknown-amdhsa -S -o offload_gcn14246.s^M
xgcc: fatal error: GCC is not configured to support amdgcn-unknown-amdhsa as
offload target^M
compilation terminated.^M
compiler exited with status 1

for each gcc-dg-prune usage.

[Bug target/89071] AVX vcvtsd2ss lets us avoid PXOR dependency breaking for scalar float<->double and other scalar xmm,xmm instructions

[peter at cordes dot ca]

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

--- Comment #2 from Peter Cordes  ---
(In reply to H.J. Lu from comment #1)
> But
> 
>   vxorps  %xmm0, %xmm0, %xmm0
>   vcvtsd2ss   %xmm1, %xmm0, %xmm0
> 
> are faster than both.

On Skylake-client (i7-6700k), I can't reproduce this result in a hand-written
asm loop.  (I was using NASM to make a static executable that runs a 100M
iteration loop so I could measure with perf).  Can you show some asm where this
performs better?

vcvtsd2ss src-reg,dst,dst is always 2 uops, regardless of the merge destination
being an xor-zeroed register.  (Either zeroed outside the loop, or inside, or
once per 4 converts with an unrolled loop.)

I can't construct a case where  vcvtsd2ss %xmm1, %xmm1, %xmm0  is worse in any
way (dependencies, uops, latency, throughput) than VXORPS + vcvtsd2ss with dst
= middle source.  I wasn't mixing it with other instructions other than VXORPS,
but I don't think anything is going to get rid of its 2nd uop, and choosing
both inputs = the same source removes any benefit from dep-breaking the output.

If adding a VXORPS helped, its probably due to some other side-effect.

Could the effect you saw have been due to code-gen changes for memory sources,
maybe  vxorps + vcvtsd2ss (mem), %xmm0, %xmm0   vs.  vmovsd + vcvtsd2ss %xmm1,
%xmm1, %xmm0?  (Those should be about equal, but memory-source SS2SD is
cheaper, no port5 uop.)



BTW, the false-dependency effect is much more obvious with SS2SD, where the
latency from src1 to output is 4 cycles, vs. 1 cycle for SD2SS.

Even without dependency-breaking, repeated

 vcvtsd2ss  %xmm1, %xmm0, %xmm0

can run at 1 per clock (same as with dep breaking), because the port-5 uop that
merges into the low 32 bits of xmm0 with 1 cycle latency is 2nd.  So latency
from xmm0 -> xmm0 for that [v]cvtsd2ss %xmm1, %xmm0 is 1 cycle.

With dep-breaking, they both still bottleneck on the port5 uop if you're doing
nothing else.

[Bug target/89071] AVX vcvtsd2ss lets us avoid PXOR dependency breaking for scalar float<->double and other scalar xmm,xmm instructions

[peter at cordes dot ca]

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

--- Comment #3 from Peter Cordes  ---
(In reply to H.J. Lu from comment #1)
I have a patch for PR 87007:
> 
> https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00298.html
> 
> which inserts a vxorps at the last possible position.  vxorps
> will be executed only once in a function.

That's talking about the mem,reg case, which like I said is different.  I
reported Bug 80571 a while ago about the mem,reg case (or gp-reg for si2ss/d),
so it's great that you have a fix for that, doing one xor-zeroing and reusing
that as a merge target for a whole function / loop.

But this bug is about the reg,reg case, where I'm pretty sure there's nothing
to be gained from xor-zeroing anything.  We can fully avoid any false dep just
by choosing both source registers = src, making the destination properly
write-only.

If you *have* an xor-zeroed register, there's no apparent harm in using it as
the merge-target for a reg-reg vcvt, vsqrt, vround, or whatever, but there's no
benefit either vs. just setting both source registers the same.  So whichever
is easier to implement, but ideally we want to avoid introducing a vxorps into
functions / blocks that don't need it at all.

[Bug target/89071] AVX vcvtsd2ss lets us avoid PXOR dependency breaking for scalar float<->double and other scalar xmm,xmm instructions

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to Peter Cordes from comment #2)
> (In reply to H.J. Lu from comment #1)
> > But
> > 
> > vxorps  %xmm0, %xmm0, %xmm0
> > vcvtsd2ss   %xmm1, %xmm0, %xmm0
> > 
> > are faster than both.
> 
> On Skylake-client (i7-6700k), I can't reproduce this result in a
> hand-written asm loop.  (I was using NASM to make a static executable that
> runs a 100M iteration loop so I could measure with perf).  Can you show some
> asm where this performs better?

Please try cvtsd2ss branch at:

https://github.com/hjl-tools/microbenchmark/

On Intel Core i7-6700K, I got

[hjl@gnu-skl-2 microbenchmark]$ make
gcc -g -I.-c -o test.o test.c
gcc -g   -c -o sse.o sse.S
gcc -g   -c -o sse-clear.o sse-clear.S
gcc -g   -c -o avx.o avx.S
gcc -g   -c -o avx2.o avx2.S
gcc -g   -c -o avx-clear.o avx-clear.S
gcc -o test test.o sse.o sse-clear.o avx.o avx2.o avx-clear.o
./test
sse  : 24533145
sse_clear: 24286462
avx  : 64117779
avx2 : 62186716
avx_clear: 58684727
[hjl@gnu-skl-2 microbenchmark]$

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #7 from Ramana Radhakrishnan  ---
(In reply to Florian Weimer from comment #0)
> In glibc, we have a test, nptl/tst-thread-exit-clobber, that attempts to
> verify if registers are properly restored by unwinding.  (The actual target
> of the the test is pthread_exit, but it covers more than that.)
> 
> This tests fails when running with GCC 9 libstdc++, even if glibc and the
> test were built with GCC 8, and libgcc_s is replaced with the version for
> GCC 8 (which works when running against GCC 8 libstdc++).
> 
> In the test, the d8 register is not restored properly during unwinding, it
> is set to zero.  d9, d10 etc. are restored.
> 
> I noticed that in GCC 9, __gxx_personality_v0 saves the d8 VFP register:
> 
> 0007b620 <__gxx_personality_v0@@CXXABI_1.3>:
>7b620:   e92d4ff0push{r4, r5, r6, r7, r8, r9, sl, fp, lr}
>7b624:   ed2d8b02vpush   {d8}
>7b628:   e3a03000mov r3, #0
>7b62c:   e1a08001mov r8, r1
> 
> And it actually uses s16 and s17, apparently for spilling integer registers.
> Perhaps the unwinder is not prepared to deal with that.

d8 is composed of s16 and s17. That should just be fine. The single precision
FP registers are packed into double precision registers in the VFP
architecture.

Ramana

[Bug c++/88358] variable template definition taken as function template declaration with implicit typename

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Mon Jan 28 22:14:27 2019
New Revision: 268343

URL: https://gcc.gnu.org/viewcvs?rev=268343&root=gcc&view=rev
Log:
PR c++/88358 - name wrongly treated as type.
* parser.c (cp_parser_direct_declarator): Don't assume a qualified-id
in parameter-list is a type if the function's declarator-id is not
qualified.

* g++.dg/cpp2a/typename1.C: Add dg-error.
* g++.dg/cpp2a/typename13.C: New test.
* g++.dg/cpp2a/typename6.C: Make a function name qualified.
Add typename.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/typename13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp2a/typename1.C
trunk/gcc/testsuite/g++.dg/cpp2a/typename6.C

[Bug c++/88358] variable template definition taken as function template declaration with implicit typename

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|accepts-invalid, patch  |rejects-valid
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Marek Polacek  ---
Fixing up the keyword.

Both issues should be fixed now.  Nicolas, thanks for reporting this.

[Bug middle-end/89002] [7/8/9 Regression] ICE in scan_omp_1_op, at omp-low.c:3166

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jan 28 22:33:33 2019
New Revision: 268345

URL: https://gcc.gnu.org/viewcvs?rev=268345&root=gcc&view=rev
Log:
PR middle-end/89002
* gimplify.c (gimplify_omp_for): When adding OMP_CLAUSE_*_GIMPLE_SEQ
for lastprivate/linear IV, push gimplify context around gimplify_assign
and, if it needed any temporaries, pop it into a gimple bind around the
sequence.

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

Added:
trunk/libgomp/testsuite/libgomp.c/pr89002.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/libgomp/ChangeLog

[Bug c/18017] -Winit-self should automatically turn on -Wuninitialized

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org
  Known to fail||4.1.3, 4.3.5, 4.4.7, 4.8.5,
   ||4.9.4, 5.4.0, 6.4.0, 7.3.0,
   ||8.2.0, 9.0
   Severity|minor   |normal

--- Comment #6 from Martin Sebor  ---
Clang has issued -Wuninitialized in C code regardless of -Winit-self since at
least as far back as 3.0.  Intel ICC enables -Wuninitialized in -Wextra (and
has since at least 13.0).  Even Visual C issues a diagnostic for the code.

It seems that it might be time for GCC to start diagnosing this as well.

[Bug middle-end/89002] [7/8/9 Regression] ICE in scan_omp_1_op, at omp-low.c:3166

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jan 28 22:34:32 2019
New Revision: 268346

URL: https://gcc.gnu.org/viewcvs?rev=268346&root=gcc&view=rev
Log:
PR middle-end/89002
* gimplify.c (gimplify_omp_for): When adding OMP_CLAUSE_*_GIMPLE_SEQ
for lastprivate/linear IV, push gimplify context around gimplify_assign
and, if it needed any temporaries, pop it into a gimple bind around the
sequence.

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

Modified:
trunk/libgomp/testsuite/libgomp.c/pr89002.c

[Bug target/89096] New: [6/7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default

[andrew at ishiboo dot com]

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

Bug ID: 89096
   Summary: [6/7/8/9 regression] AIX 7 linker rejects
_.ro_ sections by default
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew at ishiboo dot com
  Target Milestone: ---

I am trying to determine if this change in behavior is intentional or if there
is something that can be done to work with the linker default behavior...

GCC 6+ started generating sections named `_.ro_` that when passed to AIX
`ld` produce the following error:

  ld: 0711-308 SEVERE ERROR: Object main.cc.o, csect <_main.ro_>
  The csect is part of the .text section.

This happens for any such `.ro` symbol, not just the one for `main`. These are
generated in gcc/config/rs6000/rs6000.c:

  rs6000_gen_section_name (&xcoff_read_only_section_name,
   main_input_filename, ".ro_");

GCC 5 compiled objects link properly with default `ld` invocation.

In order to "fix" this and link an executable, the following flag must be
passed to deviate from default linker behavior:

   notextro or nro
Does not check to ensure that there are no load time relocation
entries for the text section of the output object file. This is
the default.

That implies default linker behavior is to reject any load time relocation
entries against the `.text` section. Can anything be done to eliminate the need
for this non-standard option or is this now required for all linking of
GCC-compiled objects?

[Bug target/89073] x86 __attribute__ ((target("sha"))) not documented

[pocqak at fyvzl dot net]

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

--- Comment #4 from Jacob Nevins  ---
Ah, should have looked harder.
Thank you for adding it to the place I looked first.

[Bug c/86125] missing -Wbuiltin-declaration-mismatch on a mismatched return type

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jan 28 23:21:10 2019
New Revision: 268348

URL: https://gcc.gnu.org/viewcvs?rev=268348&root=gcc&view=rev
Log:
PR c/86125
* c-decl.c (last_fileptr_type): Remove.
(last_structptr_types): New variable.
(match_builtin_function_types): Compare TYPE_MAIN_VARIANT of
{old,new}rettype instead of the types themselves.  Assert
last_structptr_types array has the same number of elements
as builtin_structptr_types array.  Use TYPE_MAIN_VARIANT for
argument oldtype and newtype.  Instead of handling
just fileptr_type_node specially, handle all builtin_structptr_types
pointer nodes.  Formatting fix.

* c-common.c (c_common_nodes_and_builtins): Build type variants for
builtin_structptr_types types even for C.

* gcc.dg/Wbuiltin-declaration-mismatch-7.c: Guard testcase for
lp64, ilp32 and llp64 only.
(fputs): Use unsigned long long instead of size_t for return type.
(vfprintf, vfscanf): Accept arbitrary target specific type for
va_list.

Added:
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-11.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-7.c

[Bug target/89096] [6/7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This line has been there for a long time now.
Maybe what is in main_input_filename changed ...

[Bug target/89096] [6/7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default

[andrew at ishiboo dot com]

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

--- Comment #2 from Andrew Paprocki  ---
Specifying -bnotextro does not make a working binary:

Could not load program x:
Relocation failed for x because:
Relocation entry 3 (at address 0x10416AD3)
  has an invalid l_rsecnm field.
Relocation entry 4 (at address 0x10416AD3)
  has an invalid l_rsecnm field.
Relocation entry 5 (at address 0x10416EC3)
  has an invalid l_rsecnm field.
Relocation entry 6 (at address 0x10416EC3)
  has an invalid l_rsecnm field.
Relocation entry 7 (at address 0x1041A3D3)
  has an invalid l_rsecnm field.
Relocation entry 8 (at address 0x1041A3D3)
  has an invalid l_rsecnm field.
Relocation entry 9 (at address 0x1041B813)
  has an invalid l_rsecnm field.
Relocation entry 10 (at address 0x1041B813)
  has an invalid l_rsecnm field.
Relocation entry 11 (at address 0x1041BF93)
  has an invalid l_rsecnm field.
Relocation entry 12 (at address 0x1041BF93)
  has an invalid l_rsecnm field.
Relocation entry 13 (at address 0x1041D2F3)
  has an invalid l_rsecnm field.
Relocation entry 14 (at address 0x1041D2F3)
  has an invalid l_rsecnm field.
...

[Bug fortran/89086] Add a Fortran language reference chapter

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-01-28
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
> We should add a Fortran language reference to the documentaiton.

I don't think this is realistic unless someone steps on with at least a draft.

[Bug c/89045] [9 Regression] ICE in get_parm_info, at c/c-decl.c:7518

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jan 28 23:49:51 2019
New Revision: 268349

URL: https://gcc.gnu.org/viewcvs?rev=268349&root=gcc&view=rev
Log:
PR c/89045
* c-decl.c (build_compound_literal): Don't pushdecl if in parameter
scope.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr89045.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c/89045] [9 Regression] ICE in get_parm_info, at c/c-decl.c:7518

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #26 from Jonathan Wakely  ---
Author: redi
Date: Mon Jan 28 23:58:57 2019
New Revision: 268350

URL: https://gcc.gnu.org/viewcvs?rev=268350&root=gcc&view=rev
Log:
PR libstdc++/68737 Do not use vsnprintf on HPUX

It doesn't conform to the spec, so use vsprintf with a large buffer
instead.

PR libstdc++/68737
* config/locale/generic/c_locale.h (__convert_from_v)
[_GLIBCXX_USE_C99_STDIO]: Also check _GLIBCXX_HAVE_BROKEN_VSNPRINTF.
* config/os/hpux/os_defines.h: Define _GLIBCXX_HAVE_BROKEN_VSNPRINTF.
* include/bits/locale_facets.tcc (num_put::_M_insert_float)
[_GLIBCXX_USE_C99_STDIO]: Also check _GLIBCXX_HAVE_BROKEN_VSNPRINTF.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/locale/generic/c_locale.h
trunk/libstdc++-v3/config/os/hpux/os_defines.h
trunk/libstdc++-v3/include/bits/locale_facets.tcc