[Bug target/88547] missed optimization for vector comparisons

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec 20 07:58:02 2018
New Revision: 267293

URL: https://gcc.gnu.org/viewcvs?rev=267293=gcc=rev
Log:
PR target/88547
* config/i386/i386.c (ix86_expand_sse_movcc): For maskcmp, try to
emit vpmovm2? instruction perhaps after knot?.  Reorganize code
so that it doesn't have to test !maskcmp in almost every conditional.

* gcc.target/i386/pr88547-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr88547-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/85667] (x86_64) ms_abi rules aren't followed when returning short structs with float values

[lokeshjanghel91 at gmail dot com]

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

--- Comment #5 from Lokesh Janghel  ---
>>I think we should check if type is aggregate before we return in eax and 
leave xmm0 for float and double.
>>break;
>>+ case 8:
>>+ case 4:
>>+   if (valtype != NULL_TREE && AGGREGATE_TYPE_P (valtype))
>>+ break;
>>+   if (mode == SFmode || mode == DFmode)
>>+ regno = FIRST_SSE_REG;
>>+   break;

It is working in both targets (x86_64 & mingw-w64). I tested in both targets.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[pinskia at gcc dot gnu.org]

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

--- Comment #18 from Andrew Pinski  ---
So looking into the gcc's header files, we have the following in gnu-user.h:
  "%{shared:; \
 pg|p|profile:gcrt1.o%s; \
 static:crt1.o%s; \
 " PIE_SPEC ":Scrt1.o%s; \
 :crt1.o%s} \

So every linux target uses crt1.o for non-PIE based executables.

The question I have is why is gold not doing the correct thing for those
relocations; shouldn't behaving the similar ones for other function pointers
loads?

In fact for:
int f(void);

typedef int (*h)(void);

h g(void)
{
  return f;
}

We get:
g:
adrpx0, f
add x0, x0, :lo12:f
ret

Which is exactly what is in start.S and in crt1.o.  So my guess it is a bug in
either how the runtime relocations are incorrectly being created with gold or
being resolved incorrectly inside glibc's ld.so.

Again what happens if you use BFD based ld?  Does it work?  If it does, then
can you look into the difference in the runtime relocations that are being
created?  This is the only thing which would be causing the difference.

Also note all targets have similar code like the above in crt1.o and they all
work so there must be something wrong in either gold creation of runtime
relocations or glibc's resolution of those runtime relocations (all for
AARCH64).

[Bug inline-asm/88559] error: Stack Pointer register clobbered by '%rsp' in 'asm'

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Inline-asm cannot clobber the stack pointer; espically when the operands for
input are on the stack.  GCC is correct in erroring out but it is not fully
documented that way but it should be.

[Bug c++/87275] unsequenced writes not diagnosed in constant expression

[yaghmour.shafik at gmail dot com]

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

--- Comment #3 from Shafik Yaghmour  ---
Note, I have filed similar bugs for clang:
https://bugs.llvm.org/show_bug.cgi?id=38420 and MSVC:
https://developercommunity.visualstudio.com/content/problem/304122/unsequenced-modifications-of-variable-within-a-con.html

Also see https://twitter.com/StephanTLavavej/status/1024714057603899392

[Bug inline-asm/88559] New: error: Stack Pointer register clobbered by '%rsp' in 'asm'

[jamrial at gmail dot com]

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

Bug ID: 88559
   Summary: error: Stack Pointer register clobbered by '%rsp' in
'asm'
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamrial at gmail dot com
  Target Milestone: ---

Created attachment 45265
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45265=edit
Failing pre processed output

[jamrial@ArchVM ~]$ /usr/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC)

[jamrial@ArchVM ~]$ /usr/bin/gcc -std=c11 -fPIC -pthread -g -O3 -c -o
postproc.o postproc.i

/---/

[jamrial@ArchVM ~]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/lib/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/jamrial/gcc-svn/configure --prefix=/usr/local
--libdir=/usr/local/lib --libexecdir=/usr/local/lib
--mandir=/usr/local/share/man --infodir=/usr/local/share/info
--enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-libmpx
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp
--enable-gnu-unique-object --enable-linker-build-id --enable-lto
--enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-bootstrap
--disable-werror --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 9.0.0 20181220 (experimental) (GCC)

[jamrial@ArchVM ~]$ gcc -std=c11 -fPIC -pthread -g -O3 -c -o postproc.o
postproc.i
In file included from src/libpostproc/postprocess.c:538:
src/libpostproc/postprocess_template.c: In function 'dering_MMX2':
src/libpostproc/postprocess_template.c:1097:5: error: Stack Pointer register
clobbered by '%rsp' in 'asm'
In file included from src/libpostproc/postprocess.c:540:
src/libpostproc/postprocess_template.c: In function 'dering_3DNow':
src/libpostproc/postprocess_template.c:1097:5: error: Stack Pointer register
clobbered by '%rsp' in 'asm'

/---/

This regression was introduced by a change committed between Dec 10 and Dec 17.

[Bug c++/43486] Preserve variable-use locations

[egallager at gcc dot gnu.org]

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

--- Comment #17 from Eric Gallager  ---
(In reply to David Malcolm from comment #16)
> Should be greatly improved for C++ for gcc 9 by r267272.

...but not fixed?

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[pinskia at gcc dot gnu.org]

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

--- Comment #17 from Andrew Pinski  ---
So the way i read it is crt1.o is still incorrect and not using the got for the
addreas of main. Rather it is assuming it is inside the executable.  Can you
send a line to where the discussion of the glibc qrsh done?  We can try to come
up with if it is a glibc bug or not.  Right now the assembly looks incorrect
for this case. Which makes it a glibc issue rather than gcc issue.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

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

--- Comment #16 from Stephen Kim  ---


(In reply to Andrew Pinski from comment #15)
> Let's start over.  crt1.o in glibc should support calling main that is
> located in the shared library.
> If it does not then there is a bug there.
> 
Sorry. I got notice this comment a bit late. 

Firstly, the glibc commit I posted was not correct. It seems like this commit:
 6cd380dd366d728da9f579eeb9f7f4c47f48e474

It does not. Nonetheless, a glibc maintainer, Siddhesh Poyarekar, told me that
it is NOT a glibc bug. I am not a glibc expert, so I did not find a reason that
I should not believe Siddhesh regarding glibc. 

> Can you explain why you think crt1.o is broken that it can't be used for
> that purpose?
> 
If I manually link with Scrt1.0, it works. I firstly used -Wl,-v option to see
what options are passed to Gold. Then, I just change crt1.o with Scrt1.o, which
works. Running the generate executable does not cause a segmentation fault as
the address of main is correctly found in the _start function. However, I am
not sure whether we could call it "broken crt1.o." The glibc maintainer and
also Ian Lance Taylor--the Gold developer--believed that Scrt1.o should be
given.

> Also you pointed to a commit which you said changed the behavior in glibc
> but the commit you pointed to only changes dates and nothing more.  Can you
> point to the commit which changed the behavior in glibc which caused this
> not to work any more?  
> 

I am not a glibc expert, so I am not sure about the details. I found three
commits that updated start.S probably with regard to my issue.

Here is the commit message:

AArch64: use movz/movk instead of literal pools in start.S

eXecute-Only Memory (XOM) is a protection mechanism against some ROP
attacks. XOM sets the code as executable and unreadable, so the access
to any data, like literal pools, in the code section causes the fault
with XOM. The compiler can disable literal pools for C source files,
but not for assembly files, so I use movz/movk instead of literal pools
in start.S for XOM.

I add MOVL macro with movz/movk instructions like movl pseudo-instruction
in armasm, and use the macro instead of literal pools.

* sysdeps/aarch64/start.S: Use MOVL instead of literal pools.
* sysdeps/aarch64/sysdep.h (MOVL): Add MOVL macro.


Since then, there have been multiple commits that change start.S regarding the
problem:


commit 3d1d79283e6de4f7c434cb67fb53a4fd28359669
Author: Szabolcs Nagy 
Date:   Tue Dec 19 18:43:04 2017 +

aarch64: fix static pie enabled libc when main is in a shared library

In the static pie enabled libc, crt1.o uses the same position independent
code as rcrt1.o and crt1.o is used instead of Scrt1.o when -no-pie
executables are linked.  When main is not defined in the executable, but
in a shared library crt1.o is currently broken, it assumes main is local.
(glibc has a test for this but i missed it in my previous testing.)

To make both rcrt1.o and crt1.o happy with the same code, a wrapper is
introduced around main: with this crt1.o works with extern main symbol
while rcrt1.o does not depend on GOT relocations. (The change only
affects static pie enabled libc. Further simplification of start.S is
possible in the future by using the same approach for Scrt1.o too.)

* aarch64/start.S (_start): Use __wrap_main.
(__wrap_main): New local symbol.


commit 14d886edbd3d80b771e1c42fbd9217f9074de9c6
Author: Szabolcs Nagy 
Date:   Fri Nov 17 10:45:32 2017 +

aarch64: fix start code for static pie

There are three flavors of the crt startup code:

1) crt1.o used for non-pie,
2) Scrt1.o used for dynamic linked pie (dynamic linker relocates),
3) rcrt1.o used for static linked pie (self relocation is needed)

In the --enable-static-pie case crt1.o is built with -DPIC and in case
of static linking it interposes _dl_relocate_static_pie in libc to
avoid self relocation.

Scrt1.o is built with -DPIC -DSHARED and it relies on GOT entries that
the static linker cannot relax and thus need relocation before the
start code is executed, so rcrt1.o needs separate implementation.

This implementation does not work for .text > 4G position independent
executables, which is fine since the toolchain does not support
-mcmodel=large with -fPIE.

Tests pass with ld/22269 and ld/22263 binutils bugs fixed.

* sysdeps/aarch64/start.S (_start): Handle PIC && !SHARED case.

commit 6cd380dd366d728da9f579eeb9f7f4c47f48e474 (thecommit2)
Author: Wang Boshi 
Date:   Fri Sep 15 17:53:23 2017 +0100

AArch64: use movz/movk instead of literal pools in start.S

eXecute-Only Memory (XOM) is a protection mechanism against some ROP
attacks. XOM sets the code as executable and unreadable, so the access
to any data, like literal pools, in the code 

[Bug target/83443] FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 119)

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
I can't reproduce the failures with my cross-compilers.

For instance, with an arm-none-linux-gnueabihf cross I get the expected output
for a test case reduced from the one on line 120:

$ cat u.c && /build/arm-none-linux-gnueabihf/gcc-svn/gcc/xgcc -B
/build/arm-none-linux-gnueabihf/gcc-svn/gcc -O2 -S -Wall -Wno-format
-Wformat-overflow -fexec-charset=IBM1047 u.c 
void f (char *d)
{
__builtin_sprintf (d, "%9223372036854775808i", 0);
}
u.c: In function ‘f’:
u.c:3:24: warning: ‘%9223372036854775808i’ directive width out of range
[-Wformat-overflow=]
3 |  __builtin_sprintf (d, "%9223372036854775808i", 0);
  |^~~
u.c:3:24: warning: ‘%9223372036854775808i’ directive output of
9223372036854775807 bytes causes result to exceed ‘INT_MAX’
[-Wformat-overflow=]

[Bug c++/87504] inconsistent diagnostic style between C and C++ for binary operators

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
(In reply to Rainer Orth from comment #4)
> The patch broke Solaris/SPARC bootstrap:

Sorry about that.  Does the patch posted here:
  https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01433.html
help?

[Bug tree-optimization/88553] ICE: tree check: expected ssa_name, have var_decl in SSA_VAL, at tree-ssa-sccvn.c:461

[asolokha at gmx dot com]

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

--- Comment #3 from Arseny Solokha  ---
(In reply to Richard Biener from comment #1)
> GCC 7 with
> 
> pr81768-2.c: In function ‘foo._omp_fn.1’:
> pr81768-2.c:10:9: internal compiler error: in make_decl_rtl, at varasm.c:1310

One gets ICE in make_decl_rtl on all branches by simply omitting
-ftree-loop-vectorize, as was originally reported in PR85594.

[Bug c++/87750] [8/9 Regression] Failed compilation / parsing of template member call after 'using' declaration

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #11 from Alexandre Oliva  ---
Wow, long sleep ;-)

I haven't been able to figure out what way to go, and I won't get back to this
for at least another week, so I might as well vacate the assignment until/if I
actually do get back.

[Bug c++/88196] [9 Regression] ICE on (invalid) C++ code when compiled with -std=c++2a: in convert_nontype_argument, at cp/pt.c:7137

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #3 from Alexandre Oliva  ---
This fails for the same reason, with -std=c++2a:

struct C { C *c; };
template < C > struct D;
D < ::c > d;

convert_nontype_argument doesn't even try to convert the template argument to
CLASS_TYPEs, it just asserts same_type, which, in these cases, fails.

IIUC it should attempt some constexpr conversion, but I'm not positive about
that.  Presumably we can reuse the code we use to initialize a global
constexpr, including ctor overload resolution and whatnot, but I'm not sure the
requirements for template arguments of literal class types are the same as
those for constexpr variable initialization.

Anyway, I certainly won't be able to look at this again for an entire week, so
I'll unassign it for the time being, so that anyone can feel free to take it
over.

[Bug target/85667] (x86_64) ms_abi rules aren't followed when returning short structs with float values

[mateuszb at poczta dot onet.pl]

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

mateuszb at poczta dot onet.pl changed:

   What|Removed |Added

 CC||mateuszb at poczta dot onet.pl

--- Comment #4 from mateuszb at poczta dot onet.pl ---
Now gcc 9 is heavily broken for mingw-w64 target -- so it is not fixed.
Functions that returns float or double should return in xmm0 (not eax).

In gcc-9 source code there are some hints:
gcc/config/i386/cygming.h from line #400:
/* MSVC returns aggregate types of up to 8 bytes via registers.
   See i386.c:ix86_return_in_memory.  */
#undef MS_AGGREGATE_RETURN
#define MS_AGGREGATE_RETURN 1

I think we should check if type is aggregate before we return in eax and leave
xmm0 for float and double, for example:
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 267268)
+++ gcc/config/i386/i386.c  (working copy)
@@ -9063,6 +9063,13 @@
  && !COMPLEX_MODE_P (mode))
regno = FIRST_SSE_REG;
  break;
+   case 8:
+   case 4:
+ if (valtype != NULL_TREE && AGGREGATE_TYPE_P (valtype))
+   break;
+ if (mode == SFmode || mode == DFmode)
+   regno = FIRST_SSE_REG;
+ break;
default:
  break;
 }

[Bug target/88558] New: Inline lrint, lrintf

[jsm28 at gcc dot gnu.org]

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

Bug ID: 88558
   Summary: Inline lrint, lrintf
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc*-*-*

For hard-float powerpc, GCC should support inline code generation for the lrint
/ lrintf built-in functions, subject only to -fno-math-errno (the condition
-fno-math-errno is already checked in
builtins.c:expand_builtin_int_roundingfn_2, so the back end's lrint insn
patterns do not need to check that condition).

At present, the rs6000 back end has a lrintdi2 pattern with an
unnecessarily restrictive TARGET_FPRND condition, that can inline llrint /
llrintf, and lrint / lrintf if long is 64-bit, for new-enough processors. 
(TARGET_FPRND is supposed to be for the instructions such as frin, friz etc.;
fctiw / fctid are much older instructions).  But it has nothing to generate
fctiw.  (See discussions in bug 83964, where machine-specific built-in
functions for these instructions caused problems and were removed.)

At present, glibc's bits/mathinline.h for powerpc has inlines of lrint and
lrintf for 32-bit using fctiw, but we're moving away from such inlines in glibc
headers where the compiler should be able to generate appropriate code for
built-in function calls itself.

[Bug fortran/87992] ICE in resolve_fl_variable, at fortran/resolve.c:12314

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from kargl at gcc dot gnu.org ---
Fixed on trunk.  Closing.

[Bug fortran/87992] ICE in resolve_fl_variable, at fortran/resolve.c:12314

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Dec 19 22:31:25 2018
New Revision: 267288

URL: https://gcc.gnu.org/viewcvs?rev=267288=gcc=rev
Log:
2018-12-19  Steven G. Kargl  

PR fortran/87992
* resolve.c (resolve_fl_variable): Avoid a NULL pointer.

2018-12-19  Steven G. Kargl  

PR fortran/87992
* gfortran.dg/pr87992.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr87992.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/88557] New: Lambda in template parameter list compiler segmentation fault (ICE)

[vittorio.romeo at outlook dot com]

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

Bug ID: 88557
   Summary: Lambda in template parameter list compiler
segmentation fault (ICE)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vittorio.romeo at outlook dot com
  Target Milestone: ---

The following code

template
void f() { }

causes an internal compiler error on gcc 9.x version 20181218:

: In lambda function:
:1:31: error: invalid use of 'auto'
1 | template
  |   ^
:1:31: error: could not convert '0' from 'int' to 'auto'
: At global scope:
:1:20: error: use of '' before deduction of 'auto'
1 | template
  |^~~
: In static member function 'static auto::_FUN()':
:1:20: error: invalid use of 'auto'
: At global scope:
:1:36: internal compiler error: Segmentation fault
1 | template
  |^

Live example on godbolt.org:
https://gcc.godbolt.org/z/zSKWsv

---

Similarly, the following code

template(){ return 0; }.operator()()>
void f() { }

produces another ICE:

: In member function '::operator decltype
(((const*)((const* const)0))->operator()()) (*)()() const':
:1:20: internal compiler error: in type_dependent_expression_p, at
cp/pt.c:25602
1 | template(){ return 0; }.operator()()>
  |

Live example on godbolt.org:
https://gcc.godbolt.org/z/uOfYy5

[Bug c++/88555] [9 Regression] Pack expansion fails

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-19
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

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

[Bug target/88556] New: Inline built-in sinh, cosh, tanh for -ffast-math

[jsm28 at gcc dot gnu.org]

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

Bug ID: 88556
   Summary: Inline built-in sinh, cosh, tanh for -ffast-math
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-*-*

GCC should support inline code generation for sinh, cosh, tanh functions, under
appropriate fast-math conditions.

glibc's bits/mathinline.h, for 32-bit non-SSE fast-math x86 only, has:

/* The argument range of the inline version of sinhl is slightly reduced.  */
__inline_mathcodeNP (sinh, __x, \
  register long double __exm1 = __expm1l (__fabsl (__x)); \
  return 0.5 * (__exm1 / (__exm1 + 1.0) + __exm1) * __sgn1l (__x))

__inline_mathcodeNP (cosh, __x, \
  register long double __ex = __expl (__x);   \
  return 0.5 * (__ex + 1.0 / __ex))

__inline_mathcodeNP (tanh, __x, \
  register long double __exm1 = __expm1l (-__fabsl (__x + __x));  \
  return __exm1 / (__exm1 + 2.0) * __sgn1l (-__x))

We're moving away from such inlines in glibc, preferring to leave it to the
compiler to inline standard functions under appropriate conditions.  This
inlining probably only makes sense when expm1l / expl are themselves expanded
inline (but in principle it's otherwise generic; note this x86 code uses long
double, so avoiding reducing the argument range for built-in functions for
narrower types).

flag_unsafe_math_optimizations should be required for all these expansions; the
sinh one is specifically unsafe for infinite arguments so should also require
flag_finite_math_only.

[Bug fortran/87992] ICE in resolve_fl_variable, at fortran/resolve.c:12314

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Wed, Dec 19, 2018 at 04:06:52PM +, gs...@t-online.de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87992
> 
> --- Comment #2 from G. Steinmetz  ---
> 
> It should be valid code, just as legal as
> 
> $ cat z3.f90
> subroutine s(x)
>class(*), allocatable :: x
>allocate (x, source='')
> end
> 
> $ cat z4.f90
> subroutine s(x)
>class(*), allocatable :: x
>allocate (x, source='abc')
> end
> 
> $ gfortran-9-20181216 -c z4.f90

Thanks for info.  I suppose someday I should learn more
about CLASS.

[Bug c/88546] Copy attribute unusable for weakrefs

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Testing a patch to avoid copying the attribute.

[Bug c++/88555] New: [9 Regression] Pack expansion fails

[eric at efcs dot ca]

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

Bug ID: 88555
   Summary: [9 Regression] Pack expansion fails
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

GCC fails to expand parameter packs when used in certain contexts. This is a
regression from 8.2.

https://godbolt.org/z/9MrTQQ

Reproducer:

// g++ -std=c++17
template  struct T {};

template 
void test() {
using Test = T;
}

[Bug c++/87504] inconsistent diagnostic style between C and C++ for binary operators

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #4 from Rainer Orth  ---
The patch broke Solaris/SPARC bootstrap:


/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c: In function 'void
scan_trace(dw_trace_info*, bool)':
/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2541:43: error: self-comparison
always evaluates to false [-Werror=tautological-compare]
 2541 |   && DEFAULT_INCOMING_FRAME_SP_OFFSET != INCOMING_FRAME_SP_OFFSET)
  | 

Except for i386 and stormy16, no target defines
DEFAULT_INCOMING_FRAME_SP_OFFSET,
so they get the dwarf2cfi.c default

#define DEFAULT_INCOMING_FRAME_SP_OFFSET INCOMING_FRAME_SP_OFFSET

%[@gcc-bugs@gcc.gnu.org

[qfemccza]

gcc-bugs@gcc.gnu.org
+
办理正规普通3%税票，点优惠，包真。
详电：王生
手机：1366260 7748
业QQ：958811639
++
2:16
杆共贵默

[Bug lto/88550] A compiler error when use lto: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:155

[hubicka at ucw dot cz]

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

--- Comment #2 from Jan Hubicka  ---
Dump file produced by the linker with -fdump-ipa-cgraph --save-temps (it
may end up in /tmp) would help to at least have clue what kind of symbol
caused the crash.

[Bug lto/88550] A compiler error when use lto: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:155

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-12-19
 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Component|c++ |lto
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
It's hard to do anything without a testcase but you may want to check out a
newer version from the GCC 8 branch or even GCC 9 trunk.

[Bug tree-optimization/88553] ICE: tree check: expected ssa_name, have var_decl in SSA_VAL, at tree-ssa-sccvn.c:461

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
Summary|[9 Regression] ICE: tree|ICE: tree check: expected
   |check: expected ssa_name,   |ssa_name, have var_decl in
   |have var_decl in SSA_VAL,   |SSA_VAL, at
   |at tree-ssa-sccvn.c:461 |tree-ssa-sccvn.c:461

--- Comment #2 from Richard Biener  ---
OK, so this is a DECL_VALUE_EXPR leaking from gimplifying a BB predicate
using [0][0][0] < k_57 and that getting gimplified to

_120 = .omp_data_i->b;
_121 = &*_120[0][0][0];
k_19 = _121 < k_57 ? k_57 : _23;

which means sth forgot to re-gimplify this address in the first place.

.omplow has

#pragma omp for schedule(static,32) collapse(3) nowait
private(i)
for (i = [0][0][0]; i < [0][0][10]; i = i + 4)
  for (j = [0][15][0]; j > [0][0][0]; j = j +
18446744073709551576)
for (k = [0][0][10]; k > [0][0][0]; k = k +
18446744073709551612)
D.2063 = .omp_data_i->b;
D.2064 = &*D.2063[0][0][0];
D.2039 = i - D.2064;
D.2040 = D.2039 /[ex] 4;

is lowering already missed here?

Jakub, you are more familiar with this - as said, it's latent everywhere.

[Bug c++/88554] [9 Regression] Segfault ICE when falling off the end of a reference-returning friend operator

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Oh that's definitely not right, because we don't want a fix-it for friend
functions, where *this isn't valid.

So this seems better:

--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -16092,6 +16092,7 @@ finish_function (bool inline_p)
{
  tree valtype = TREE_TYPE (DECL_RESULT (fndecl));
  if (TREE_CODE (valtype) == REFERENCE_TYPE
+ && current_class_ref
  && same_type_ignoring_top_level_qualifiers_p
  (TREE_TYPE (valtype), TREE_TYPE (current_class_ref)))
if (global_dc->option_enabled (OPT_Wreturn_type,

[Bug tree-optimization/88553] [9 Regression] ICE: tree check: expected ssa_name, have var_decl in SSA_VAL, at tree-ssa-sccvn.c:461

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-19
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  GCC 8 ICEs with

during GIMPLE pass: ifcvt
pr81768-2.c: In function ‘foo._omp_fn.1’:
pr81768-2.c:10:9: internal compiler error: in execute_todo, at passes.c:2043
 #pragma omp target parallel for schedule(static, 32) collapse(3)
 ^~~
0xec47fc execute_todo
/space/rguenther/src/svn/gcc-8-branch/gcc/passes.c:2043
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

GCC 7 with

pr81768-2.c: In function ‘foo._omp_fn.1’:
pr81768-2.c:10:9: internal compiler error: in make_decl_rtl, at varasm.c:1310
 #pragma omp target parallel for schedule(static, 32) collapse(3)
 ^~~
0x12debba make_decl_rtl(tree_node*)
/space/rguenther/src/svn/gcc-7-branch/gcc/varasm.c:1306
0xac61f0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/space/rguenther/src/svn/gcc-7-branch/gcc/expr.c:9873
0xabeec1 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/space/rguenther/src/svn/gcc-7-branch/gcc/expr.c:8141
0xaa5945 expand_expr

all probably the same underlying issue of if-conversion mucking up SSA form
in unexpected ways.

[Bug c++/88554] [9 Regression] Segfault ICE when falling off the end of a reference-returning friend operator

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
This fixes the ICE but I don't know if it's right and haven't tested it any
further:

--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -16093,7 +16093,7 @@ finish_function (bool inline_p)
  tree valtype = TREE_TYPE (DECL_RESULT (fndecl));
  if (TREE_CODE (valtype) == REFERENCE_TYPE
  && same_type_ignoring_top_level_qualifiers_p
- (TREE_TYPE (valtype), TREE_TYPE (current_class_ref)))
+ (TREE_TYPE (valtype), current_class_type))
if (global_dc->option_enabled (OPT_Wreturn_type,
   global_dc->option_state))
  add_return_star_this_fixit (, fndecl);

[Bug c++/88554] [9 Regression] Segfault ICE when falling off the end of a reference-returning friend operator

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> Started to ICE (rather than give a -Wreturn-type diagnostic) with r263298
> 
> Add fix-it hint for missing return statement in assignment operators (PR
> c++/85523)

Hmm, apparently this commit has my name on it too.

It fails in contains_struct_check because __t is null:

#0  0x008d37a5 in contains_struct_check (__t=0x0, __s=TS_TYPED,
__f=0x18dc780 "/home/jwakely/src/gcc/gcc/gcc/cp/decl.c", __l=16096,
__g=0x18e5640  "finish_function") at
/home/jwakely/src/gcc/gcc/gcc/tree.h:3270
#1  0x008ce6f7 in finish_function (inline_p=true) at
/home/jwakely/src/gcc/gcc/gcc/cp/decl.c:16096
#2  0x0097260a in cp_parser_function_definition_after_declarator
(parser=parser@entry=0x77ff6ab0, inline_p=inline_p@entry=true) at
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:27498
#3  0x0097382d in cp_parser_late_parsing_for_member(cp_parser*,
tree_node*) () at /home/jwakely/src/gcc/gcc/gcc/cp/parser.c:28379
#4  0x00953f62 in cp_parser_class_specifier_1(cp_parser*) () at
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:23384
#5  0x009552fa in cp_parser_class_specifier (parser=0x77ff6ab0) at
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:23410
#6  cp_parser_type_specifier(cp_parser*, int, cp_decl_specifier_seq*, bool,
int*, bool*) () at /home/jwakely/src/gcc/gcc/gcc/cp/parser.c:17266
#7  0x009562cc in cp_parser_decl_specifier_seq(cp_parser*, int,
cp_decl_specifier_seq*, int*) () at
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:27347
#8  0x009569d1 in cp_parser_simple_declaration(cp_parser*, bool,
tree_node**) () at /home/jwakely/src/gcc/gcc/gcc/cp/parser.c:13292
#9  0x00979c93 in cp_parser_declaration(cp_parser*) () at
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:13111
#10 0x0097a43d in cp_parser_translation_unit (parser=0x77ff6ab0) at
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:4688
#11 c_parse_file() () at /home/jwakely/src/gcc/gcc/gcc/cp/parser.c:40855
#12 0x00a83f21 in c_common_parse_file () at
/home/jwakely/src/gcc/gcc/gcc/c-family/c-opts.c:1151
#13 0x00f1decf in compile_file () at
/home/jwakely/src/gcc/gcc/gcc/toplev.c:456
#14 0x008184aa in do_compile () at
/home/jwakely/src/gcc/gcc/gcc/toplev.c:2176
#15 toplev::main(int, char**) () at /home/jwakely/src/gcc/gcc/gcc/toplev.c:2311
#16 0x0081ba9b in main (argc=20, argv=0x7fffd848) at
/home/jwakely/src/gcc/gcc/gcc/main.c:39

That comes from TREE_TYPE (current_class_ref) where current_class_ref is null.

[Bug translation/80191] diagnostic placeholder "new initializer" must be marked for translation

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
I think quoting/translating grammar terms is a general problem in the C++
front-end (perhaps to a lesser extent also in the rest of GCC as well).  The
inconsistencies it leads to can be seen in the translated messages.  For
instance, de.po has these two messages:

#: cp/init.c:2906
#, gcc-internal-format
msgid "array size in new-expression must be constant"
msgstr "Arraygröße in »new«-Ausdruck muss konstant sein"

and

#: cp/parser.c:8454
#, gcc-internal-format
msgid "initialization of new-expression for type % requires exactly one
element"
msgstr "Initialisierung des new-Ausdrucks für Typ % erfordert genau ein
Element"

In the first one, 'new' is quoted as if it was a keyword, but in the second one
it isn't (as it shouldn't be).

Another example is one of inconsistent translation (it's not the fault of the
translator -- the msgid mixes plain English text with a grammar term/expression
syntax without making it clear what ends where):

#: cp/parser.c:37546
#, gcc-internal-format
msgid "expected id-expression (arguments)"
msgstr "»id-expression (arguments)« erwartet"

#: cp/parser.c:5790
#, gcc-internal-format
msgid "expected id-expression"
msgstr "ID-Ausdruck erwartet"

I don't know what the text of the C++ standard reads like in German to say what
the right way to  solve this is.  Does the German text refer to 'new'-Ausdruck
in the grammar, or does it use '/new-expression/' like the English edition, or
something else?

Roland?

(GCC is also inconsistent in the hyphenation of grammar terms like
"constant-expression" and so is the translation.)

[Bug c++/88554] [9 Regression] Segfault ICE when falling off the end of a reference-returning friend operator

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Arthur O'Dwyer from comment #0)
> This is happening in trunk but not in GCC 8.2, so it must be a very recent
> regression.

You can't assume that, gcc-8-branch was branched from trunk in April.

It regressed in early August.

[Bug c++/88554] [9 Regression] Segfault ICE when falling off the end of a reference-returning friend operator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-19
 CC||dmalcolm at gcc dot gnu.org
   Target Milestone|--- |9.0
Summary|Segfault ICE when falling   |[9 Regression] Segfault ICE
   |off the end of a|when falling off the end of
   |reference-returning friend  |a reference-returning
   |operator|friend operator
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Started to ICE (rather than give a -Wreturn-type diagnostic) with r263298

Add fix-it hint for missing return statement in assignment operators (PR
c++/85523)

gcc/cp/ChangeLog:

PR c++/85523
* decl.c: Include "gcc-rich-location.h".
(add_return_star_this_fixit): New function.
(finish_function): When warning about missing return statements in
functions returning non-void, add a "return *this;" fix-it hint for
assignment operators.

gcc/testsuite/ChangeLog:

PR c++/85523
* g++.dg/pr85523.C: New test.

[Bug c++/88554] New: Segfault ICE when falling off the end of a reference-returning friend operator

[arthur.j.odwyer at gmail dot com]

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

Bug ID: 88554
   Summary: Segfault ICE when falling off the end of a
reference-returning friend operator
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

struct X {
friend X& operator+=(X&, int) { }
};

https://godbolt.org/z/17PLVW
: In function 'X& operator+=(X&, int)':
:3:37: internal compiler error: Segmentation fault
3 | friend X& operator+=(X&, int) { }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I assume GCC is trying to give a helpful diagnostic about the missing `return`
statement and following a null pointer in the process. Changing the name of the
friend function from `operator+=` to `foo` makes the segfault disappear.

This is happening in trunk but not in GCC 8.2, so it must be a very recent
regression.

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

[samtebbs at gcc dot gnu.org]

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

samtebbs at gcc dot gnu.org changed:

   What|Removed |Added

 CC||samtebbs at gcc dot gnu.org

--- Comment #9 from samtebbs at gcc dot gnu.org ---
The gcc.target/aarch64/combine_bfxil.c failure has been addressed by this patch
proposal: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01401.html

gcc/testsuite/Changelog:

2018-12-19  Sam Tebbs  

 * gcc.target/aarch64/combine_bfxil.c: Change 
scan-assembler-times bfxil count to 18.

[Bug lto/58042] MinGW GCC produces problematic x64 executable with -O2 -static -flto -m64

[test_avto22 at mail dot ru]

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

Michael K.  changed:

   What|Removed |Added

 CC||test_avto22 at mail dot ru

--- Comment #2 from Michael K.  ---
It's persistently reproducable with current 8.2.0

There's some more info here https://sourceforge.net/p/mingw-w64/bugs/644/#5101

I've managed trace down to this point
https://github.com/gcc-mirror/gcc/blob/master/gcc/tree.c#L5495
that is, TYPE_BINFO (type) = NULL resolving the issue

[Bug tree-optimization/88553] New: [9 Regression] ICE: tree check: expected ssa_name, have var_decl in SSA_VAL, at tree-ssa-sccvn.c:461

[asolokha at gmx dot com]

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

Bug ID: 88553
   Summary: [9 Regression] ICE: tree check: expected ssa_name,
have var_decl in SSA_VAL, at tree-ssa-sccvn.c:461
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-9.0.0-alpha2018 snapshot (r266019) ICEs when compiling
gcc/testsuite/gcc.dg/gomp/pr81768-2.c at any optimization level and w/ -fopenmp
-ftree-loop-vectorize -fwrapv:

% gcc-9.0.0-alpha20181216 -O1 -fopenmp -ftree-loop-vectorize -fwrapv -c
gcc/testsuite/gcc.dg/gomp/pr81768-2.c
during GIMPLE pass: ifcvt
gcc/testsuite/gcc.dg/gomp/pr81768-2.c: In function 'foo._omp_fn.1':
gcc/testsuite/gcc.dg/gomp/pr81768-2.c:10:9: internal compiler error: tree
check: expected ssa_name, have var_decl in SSA_VAL, at tree-ssa-sccvn.c:462
   10 | #pragma omp target parallel for schedule(static, 32) collapse(3)
  | ^~~
0x6dd283 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree.c:9757
0x6bddf3 tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree.h:3157
0x6bddf3 SSA_VAL(tree_node*, bool*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree-ssa-sccvn.c:462
0x6bddf3 vuse_ssa_val
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree-ssa-sccvn.c:480
0x6bddf3 vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree-ssa-sccvn.c:2626
0xeb9301 visit_reference_op_load
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree-ssa-sccvn.c:3979
0xeb9301 visit_stmt
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree-ssa-sccvn.c:4397
0xeba68d process_bb
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree-ssa-sccvn.c:6047
0xebbe1d do_rpo_vn
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree-ssa-sccvn.c:6654
0xebd008 do_rpo_vn(function*, edge_def*, bitmap_head*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree-ssa-sccvn.c:6743
0xd7af41 tree_if_conversion(loop*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree-if-conv.c:3066
0xd7c626 execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree-if-conv.c:3142
0xd7c626 execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181216/work/gcc-9-20181216/gcc/tree-if-conv.c:3130

It was initially reported in PR85594 comment 2, but that made little sense as
it's most likely an unrelated issue manifesting itself at a different level of
the compilation pipeline.

[Bug fortran/88552] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1120

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-19
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from at least 4.8 up to trunk (9.0).

[Bug target/88547] missed optimization for vector comparisons

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 45264
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45264=edit
gcc9-pr88547-1.patch

Untested patch to improve the avx512* sse_movcc.

[Bug fortran/88552] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1120

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

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

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

Detected :


$ cat z2.f90
program p
integer(len((c)) :: n
end


$ cat z5.f90
implicit none
integer(len((c)) :: n
end


$ gfortran-9-20181216 -c z2.f90 -fimplicit-none
z2.f90:2:14:

2 | integer(len((c)) :: n
  |  1
Error: Symbol 'c' at (1) has no IMPLICIT type

[Bug fortran/88552] New: ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1120

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

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

Bug ID: 88552
   Summary: ICE in gfc_typenode_for_spec, at
fortran/trans-types.c:1120
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Without a program statement :


$ cat z1.f90
integer(len((c)) :: n
end


$ gfortran-9-20181216 -c z1.f90
$ gfortran-9-20181216 -c z1.f90 -fimplicit-none
z1.f90:1:0:

1 | integer(len((c)) :: n
  |
internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1120
0x78e59d gfc_typenode_for_spec(gfc_typespec*, int)
../../gcc/fortran/trans-types.c:1120
0x78c1f6 gfc_sym_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2243
0x71af9e gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1696
0x71ea47 generate_local_decl
../../gcc/fortran/trans-decl.c:5600
0x6d3d12 do_traverse_symtree
../../gcc/fortran/symbol.c:4151
0x71ff9c generate_local_vars
../../gcc/fortran/trans-decl.c:5800
0x71ff9c gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6444
0x69d7c6 translate_all_program_units
../../gcc/fortran/parse.c:6128
0x69d7c6 gfc_parse_file()
../../gcc/fortran/parse.c:6331
0x6e6fcf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204


---

Invalid syntax also silently accepted :

$ cat z3.f90
integer(m::n
end


$ gfortran-9-20181216 -c z3.f90
$ gfortran-9-20181216 -c z3.f90 -fimplicit-none
z3.f90:1:0:

1 | integer(m::n
  |
internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1120
#...

[Bug fortran/87992] ICE in resolve_fl_variable, at fortran/resolve.c:12314

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

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

--- Comment #2 from G. Steinmetz  ---

It should be valid code, just as legal as


$ cat z3.f90
subroutine s(x)
   class(*), allocatable :: x
   allocate (x, source='')
end


$ cat z4.f90
subroutine s(x)
   class(*), allocatable :: x
   allocate (x, source='abc')
end


$ gfortran-9-20181216 -c z4.f90
$

[Bug target/86487] [7/8/9 Regression] insn does not satisfy its constraints on arm big-endian

[avieira at gcc dot gnu.org]

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

--- Comment #8 from avieira at gcc dot gnu.org ---
Oliver,

Your new example doesn't seem to be hitting the same issue as the first one.
The first failure was being caused by paradoxical subregs, the second one
doesn't have paradoxical subregs.

I'll try to investigate it.

[Bug c++/43064] improve location and text of diagnostics in constructor initializer lists

[jg at jguk dot org]

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

--- Comment #12 from Jonny Grant  ---
(In reply to David Malcolm from comment #11)
> Should be fixed (for gcc 9) by r267272.

Fantastic David!

[Bug c++/88375] Vague source location for bad initialization

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed for GCC 9 (for C++) by r267276.

[Bug c++/87504] inconsistent diagnostic style between C and C++ for binary operators

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
After r267273, g++ emits:

test.cc:10:30: error: invalid operands of types ‘const char [6]’ and ‘const
char’ to binary ‘operator&’
   10 |   return __builtin_strnlen (a[v0], n);
  | ~^~
  | | |
  | | const char
  | const char [6]

showing the types of the LHS and RHS (and using different colors for them).

The message isn't changed yet, so keeping this open.

[Bug c++/43486] Preserve variable-use locations

[dmalcolm at gcc dot gnu.org]

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

--- Comment #16 from David Malcolm  ---
Should be greatly improved for C++ for gcc 9 by r267272.

[Bug c++/43064] improve location and text of diagnostics in constructor initializer lists

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #11 from David Malcolm  ---
Should be fixed (for gcc 9) by r267272.

[Bug c++/88375] Vague source location for bad initialization

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Author: dmalcolm
Date: Wed Dec 19 15:22:27 2018
New Revision: 267276

URL: https://gcc.gnu.org/viewcvs?rev=267276=gcc=rev
Log:
C++: better locations for bogus initializations (PR c++/88375)

PR c++/88375 reports that errors relating to invalid conversions in
initializations are reported at unhelpfully vague locations, as in
e.g.:

enum struct a : int {
  one, two
};

struct foo {
  int e1, e2;
  a e3;
} arr[] = {
  { 1, 2, a::one },
  { 3, a::two },
  { 4, 5, a::two }
};

for which g++ trunk emits the vague:

pr88375.cc:12:1: error: cannot convert 'a' to 'int' in initialization
   12 | };
  | ^

with the error at the final closing brace.

This patch uses location information for the initializers, converting the
above to:

pr88375.cc:10:11: error: cannot convert 'a' to 'int' in initialization
   10 |   { 3, a::two },
  |~~~^~~
  |   |
  |   a

highlighting which subexpression is problematic, and its type.

Ideally we'd also issue a note showing the field decl being initialized,
but that turned out to be more invasive.

gcc/cp/ChangeLog:
PR c++/88375
* typeck.c (convert_for_assignment): Capture location of rhs
before stripping, and if available.  Use the location when
complaining about bad conversions, labelling it with the
rhstype if the location was present.
* typeck2.c (digest_init_r): Capture location of init before
stripping.

gcc/testsuite/ChangeLog:
PR c++/88375
* g++.dg/init/pr88375-2.C: New test.
* g++.dg/init/pr88375.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/init/pr88375-2.C
trunk/gcc/testsuite/g++.dg/init/pr88375.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/87504] inconsistent diagnostic style between C and C++ for binary operators

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Author: dmalcolm
Date: Wed Dec 19 15:15:42 2018
New Revision: 267273

URL: https://gcc.gnu.org/viewcvs?rev=267273=gcc=rev
Log:
C++: improvements to binary operator diagnostics (PR c++/87504)

The C frontend is able (where expression locations are available) to print
problems with binary operators in 3-location form, labelling the types of
the expressions:

  arg_0 op arg_1
  ~ ^~ ~
||
|arg1 type
arg0 type

The C++ frontend currently just shows the combined location:

  arg_0 op arg_1
  ~~^~~~

and fails to highlight where the subexpressions are, or their types.

This patch introduces a op_location_t struct for handling the above
operator-location vs combined-location split, and a new
class binary_op_rich_location for displaying the above, so that the
C++ frontend is able to use the more detailed 3-location form for
type mismatches in binary operators, and for -Wtautological-compare
(where types are not displayed).  Both forms can be seen in this
example:

bad-binary-ops.C:69:20: error: no match for 'operator&&' (operand types are
  's' and 't')
   69 |   return ns_4::foo && ns_4::inner::bar;
  |  ~ ^~ 
  ||   |
  |s   t
bad-binary-ops.C:69:20: note: candidate: 'operator&&(bool, bool)' 
   69 |   return ns_4::foo && ns_4::inner::bar;
  |  ~~^~~

The patch also allows for some uses of macros in
-Wtautological-compare, where both sides of the comparison have
been spelled the same way, e.g.:

Wtautological-compare-ranges.c:23:11: warning: self-comparison always
   evaluates to true [-Wtautological-compare]
   23 |   if (FOO == FOO);
  |   ^~

gcc/c-family/ChangeLog:
PR c++/87504
* c-common.h (warn_tautological_cmp): Convert 1st param from
location_t to const op_location_t &.
* c-warn.c (find_array_ref_with_const_idx_r): Call fold_for_warn
when testing for INTEGER_CST.
(warn_tautological_bitwise_comparison): Convert 1st param from
location_t to const op_location_t &; use it to build a
binary_op_rich_location, and use this.
(spelled_the_same_p): New function.
(warn_tautological_cmp): Convert 1st param from location_t to
const op_location_t &.  Warn for macro expansions if
spelled_the_same_p.  Use binary_op_rich_location.

gcc/c/ChangeLog:
PR c++/87504
* c-typeck.c (class maybe_range_label_for_tree_type_mismatch):
Move from here to gcc-rich-location.h and gcc-rich-location.c.
(build_binary_op): Use struct op_location_t and
class binary_op_rich_location.

gcc/cp/ChangeLog:
PR c++/87504
* call.c (op_error): Convert 1st param from location_t to
const op_location_t &.  Use binary_op_rich_location for binary
ops.
(build_conditional_expr_1): Convert 1st param from location_t to
const op_location_t &.
(build_conditional_expr): Likewise.
(build_new_op_1): Likewise.
(build_new_op): Likewise.
* cp-tree.h (build_conditional_expr): Likewise.
(build_new_op): Likewise.
(build_x_binary_op): Likewise.
(cp_build_binary_op): Likewise.
* parser.c (cp_parser_primary_expression): Build a location
for id-expression nodes.
(cp_parser_binary_expression): Use an op_location_t when
calling build_x_binary_op.
(cp_parser_operator): Build a location for user-defined literals.
* typeck.c (build_x_binary_op): Convert 1st param from location_t
to const op_location_t &.
(cp_build_binary_op): Likewise.  Use binary_op_rich_location.

gcc/ChangeLog:
PR c++/87504
* gcc-rich-location.c
(maybe_range_label_for_tree_type_mismatch::get_text): Move here from
c/c-typeck.c.
(binary_op_rich_location::binary_op_rich_location): New ctor.
(binary_op_rich_location::use_operator_loc_p): New function.
* gcc-rich-location.h
(class maybe_range_label_for_tree_type_mismatch)): Move here from
c/c-typeck.c.
(struct op_location_t): New forward decl.
(class binary_op_rich_location): New class.
* tree.h (struct op_location_t): New struct.

gcc/testsuite/ChangeLog:
* c-c++-common/Wtautological-compare-ranges.c: New test.
* g++.dg/cpp0x/pr51420.C: Add -fdiagnostics-show-caret and update
expected output.
* g++.dg/diagnostic/bad-binary-ops.C: Update expected output from
1-location form to 3-location form, with labelling of ranges with
types.  Add examples of id-expression nodes with namespaces.
* g++.dg/diagnostic/param-type-mismatch-2.C: Likewise.


Added:
trunk/gcc/testsuite/c-c++-common/Wtautological-compare-ranges.c
Modified:

[Bug c++/43064] improve location and text of diagnostics in constructor initializer lists

[dmalcolm at gcc dot gnu.org]

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

--- Comment #10 from David Malcolm  ---
Author: dmalcolm
Date: Wed Dec 19 15:08:21 2018
New Revision: 267272

URL: https://gcc.gnu.org/viewcvs?rev=267272=gcc=rev
Log:
C++: more location wrapper nodes (PR c++/43064, PR c++/43486)

This is v6 of the patch, as posted to:
  https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01331.html


The C++ frontend gained various location wrapper nodes in r256448 (GCC 8).
That patch:
  https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00799.html
added wrapper nodes around all nodes with !CAN_HAVE_LOCATION_P for:

* arguments at callsites, and for

* typeid, alignof, sizeof, and offsetof.

This is a followup to that patch, adding many more location wrappers
to the C++ frontend.  It adds location wrappers for nodes with
!CAN_HAVE_LOCATION_P to:

* all literal nodes (in cp_parser_primary_expression)

* all id-expression nodes (in finish_id_expression), except within a
  decltype.

* all mem-initializer nodes within a mem-initializer-list
  (in cp_parser_mem_initializer)

However, the patch also adds some suppressions: regions in the parser
for which wrapper nodes will not be created:

* within a template-parameter-list or template-argument-list (in
  cp_parser_template_parameter_list and cp_parser_template_argument_list
  respectively), to avoid encoding the spelling location of the nodes
  in types.  For example, "array<10>" and "array<10>" are the same type,
  despite the fact that the two different "10" tokens are spelled in
  different locations in the source.

* within a gnu-style attribute (none of are handlers are set up to cope
  with location wrappers yet)

* within various OpenMP clauses

The patch enables various improvements to locations for bad
initializations, for -Wchar-subscripts, and enables various other
improvements in the followup patch.

For example, given the followup buggy mem-initializer:

class X {
  X() : bad(42),
good(42)
  { }
  void* bad;
  int good;
};

previously, our diagnostic was on the final close parenthesis of the
mem-initializer-list, leaving it unclear where the problem is:

t.cc: In constructor 'X::X()':
t.cc:3:16: error: invalid conversion from 'int' to 'void*' [-fpermissive]
3 | good(42)
  |^
  ||
  |int

whereas with the patch we highlight which expression is bogus:

t.cc: In constructor 'X::X()':
t.cc:2:13: error: invalid conversion from 'int' to 'void*' [-fpermissive]
2 |   X() : bad(42),
  | ^~
  | |
  | int

Similarly, the diagnostic for this bogus initialization:

i.cc:1:44: error: initializer-string for array of chars is too long
[-fpermissive]
1 | char test[3][4] = { "ok", "too long", "ok" };
  |^

is improved by the patch so that it indicates which string is too long:

i.cc:1:27: error: initializer-string for array of chars is too long
[-fpermissive]
1 | char test[3][4] = { "ok", "too long", "ok" };
  |   ^~


gcc/c-family/ChangeLog:
PR c++/43064
PR c++/43486
* c-common.c (unsafe_conversion_p): Fold any location wrapper.
(verify_tree): Handle location wrappers.
(c_common_truthvalue_conversion): Strip any location wrapper.
Handle CONST_DECL.
(fold_offsetof): Strip any location wrapper.
(complete_array_type): Likewise for initial_value.
(convert_vector_to_array_for_subscript): Call fold_for_warn on the
index before checking for INTEGER_CST.
* c-pretty-print.c (c_pretty_printer::primary_expression): Don't
print parentheses around location wrappers.
* c-warn.c (warn_logical_operator): Call fold_for_warn on op_right
before checking for INTEGER_CST.
(warn_tautological_bitwise_comparison): Call
tree_strip_any_location_wrapper on lhs, rhs, and bitop's operand
before checking for INTEGER_CST.
(readonly_error): Strip any location wrapper.
(warn_array_subscript_with_type_char): Strip location wrappers
before checking for INTEGER_CST.  Use the location of the index if
available.

gcc/ChangeLog:
PR c++/43064
PR c++/43486
* convert.c: Include "selftest.h".
(preserve_any_location_wrapper): New function.
(convert_to_pointer_maybe_fold): Update to handle location
wrappers.
(convert_to_real_maybe_fold): Likewise.
(convert_to_integer_1): Strip expr when using TREE_OVERFLOW.
Handle location wrappers when checking for INTEGER_CST.
(convert_to_integer_maybe_fold): Update to handle location
wrappers.
(convert_to_complex_maybe_fold): Likewise.
(selftest::test_convert_to_integer_maybe_fold): New functions.
(selftest::convert_c_tests): New function.
* convert.h (preserve_any_location_wrapper): New decl.
  

[Bug c++/43486] Preserve variable-use locations

[dmalcolm at gcc dot gnu.org]

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

--- Comment #15 from David Malcolm  ---
Author: dmalcolm
Date: Wed Dec 19 15:08:21 2018
New Revision: 267272

URL: https://gcc.gnu.org/viewcvs?rev=267272=gcc=rev
Log:
C++: more location wrapper nodes (PR c++/43064, PR c++/43486)

This is v6 of the patch, as posted to:
  https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01331.html


The C++ frontend gained various location wrapper nodes in r256448 (GCC 8).
That patch:
  https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00799.html
added wrapper nodes around all nodes with !CAN_HAVE_LOCATION_P for:

* arguments at callsites, and for

* typeid, alignof, sizeof, and offsetof.

This is a followup to that patch, adding many more location wrappers
to the C++ frontend.  It adds location wrappers for nodes with
!CAN_HAVE_LOCATION_P to:

* all literal nodes (in cp_parser_primary_expression)

* all id-expression nodes (in finish_id_expression), except within a
  decltype.

* all mem-initializer nodes within a mem-initializer-list
  (in cp_parser_mem_initializer)

However, the patch also adds some suppressions: regions in the parser
for which wrapper nodes will not be created:

* within a template-parameter-list or template-argument-list (in
  cp_parser_template_parameter_list and cp_parser_template_argument_list
  respectively), to avoid encoding the spelling location of the nodes
  in types.  For example, "array<10>" and "array<10>" are the same type,
  despite the fact that the two different "10" tokens are spelled in
  different locations in the source.

* within a gnu-style attribute (none of are handlers are set up to cope
  with location wrappers yet)

* within various OpenMP clauses

The patch enables various improvements to locations for bad
initializations, for -Wchar-subscripts, and enables various other
improvements in the followup patch.

For example, given the followup buggy mem-initializer:

class X {
  X() : bad(42),
good(42)
  { }
  void* bad;
  int good;
};

previously, our diagnostic was on the final close parenthesis of the
mem-initializer-list, leaving it unclear where the problem is:

t.cc: In constructor 'X::X()':
t.cc:3:16: error: invalid conversion from 'int' to 'void*' [-fpermissive]
3 | good(42)
  |^
  ||
  |int

whereas with the patch we highlight which expression is bogus:

t.cc: In constructor 'X::X()':
t.cc:2:13: error: invalid conversion from 'int' to 'void*' [-fpermissive]
2 |   X() : bad(42),
  | ^~
  | |
  | int

Similarly, the diagnostic for this bogus initialization:

i.cc:1:44: error: initializer-string for array of chars is too long
[-fpermissive]
1 | char test[3][4] = { "ok", "too long", "ok" };
  |^

is improved by the patch so that it indicates which string is too long:

i.cc:1:27: error: initializer-string for array of chars is too long
[-fpermissive]
1 | char test[3][4] = { "ok", "too long", "ok" };
  |   ^~


gcc/c-family/ChangeLog:
PR c++/43064
PR c++/43486
* c-common.c (unsafe_conversion_p): Fold any location wrapper.
(verify_tree): Handle location wrappers.
(c_common_truthvalue_conversion): Strip any location wrapper.
Handle CONST_DECL.
(fold_offsetof): Strip any location wrapper.
(complete_array_type): Likewise for initial_value.
(convert_vector_to_array_for_subscript): Call fold_for_warn on the
index before checking for INTEGER_CST.
* c-pretty-print.c (c_pretty_printer::primary_expression): Don't
print parentheses around location wrappers.
* c-warn.c (warn_logical_operator): Call fold_for_warn on op_right
before checking for INTEGER_CST.
(warn_tautological_bitwise_comparison): Call
tree_strip_any_location_wrapper on lhs, rhs, and bitop's operand
before checking for INTEGER_CST.
(readonly_error): Strip any location wrapper.
(warn_array_subscript_with_type_char): Strip location wrappers
before checking for INTEGER_CST.  Use the location of the index if
available.

gcc/ChangeLog:
PR c++/43064
PR c++/43486
* convert.c: Include "selftest.h".
(preserve_any_location_wrapper): New function.
(convert_to_pointer_maybe_fold): Update to handle location
wrappers.
(convert_to_real_maybe_fold): Likewise.
(convert_to_integer_1): Strip expr when using TREE_OVERFLOW.
Handle location wrappers when checking for INTEGER_CST.
(convert_to_integer_maybe_fold): Update to handle location
wrappers.
(convert_to_complex_maybe_fold): Likewise.
(selftest::test_convert_to_integer_maybe_fold): New functions.
(selftest::convert_c_tests): New function.
* convert.h (preserve_any_location_wrapper): New decl.
  

[Bug target/88547] missed optimization for vector comparisons

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
For 64-byte vectors, we emit
vpcmpgtb%zmm1, %zmm0, %k1
vpxor   %xmm1, %xmm1, %xmm1
vpternlogd  $0xFF, %zmm0, %zmm0, %zmm0
vmovdqu8%zmm1, %zmm0{%k1}
for f1, perhaps it would be better to emit:
vpcmpgtb%zmm1, %zmm0, %k1
knotq   %k1, %k1
vpmovm2b%k1, %zmm0
?

[Bug c++/87841] Member of class template hides template parameter of another member

[o_kniemeyer at maxon dot net]

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

--- Comment #5 from Ole Kniemeyer  ---
Thanks for asking the committee. I think the standard makes sense as it is,
because otherwise there is no chance to name the template parameter (that's
what I need in my specific situation where I found the bug). Also the standard
is what I would expect as the template parameter is "closer" to the function
template as a member type of the enclosing class.

[Bug fortran/88551] New: passing a portion of an array of a derived type that contains an allocatable component

[hassani at unice dot fr]

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

Bug ID: 88551
   Summary: passing a portion of an array of a derived type that
contains an allocatable component
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hassani at unice dot fr
  Target Milestone: ---

gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0

gfortran --version
GNU Fortran (Homebrew GCC 8.2.0) 8.2.0
-
Dear all,
It seems that passing a portion of an array of a DT which has an allocatable
component to a subroutine can lead to memory leaks.

Here is a small program that reproduces this situation:

program test_leaks
  implicit none

  type :: vint_t
 integer, allocatable :: col(:)
  end type vint_t

  type(vint_t) :: row(4)
  integer  :: i, Ind(2)=[3,2]

  do i = 1, 4
 allocate(row(i)%col(i))
  end do

  row(1)%col(1) = 11  
  row(2)%col(1) = 21 ; row(2)%col(2) = 22
  row(3)%col(1) = 31 ; row(3)%col(2) = 32 ; row(3)%col(3) = 33
  row(4)%col(1) = 41 ; row(4)%col(2) = 42 ; row(4)%col(3) = 43 ; row(4)%col(4)
= 44

  do i = 1, 100
 call do_nothing ( row(Ind) )

 if (mod(i,1) == 0) then
print*,i ; read*
 end if
  end do

contains

  subroutine do_nothing ( a )
type(vint_t), intent(in) :: a(:)
  end subroutine do_nothing

end program test_leaks

- The memory usage grows linearly with iterations when compiled on mac OS
10.14.2 with gfortran 8.2.0
- But the program works well (in the sense that a print in "do_nothing" shows
the expected values)
- The problem also occurs with an allocatable character component.
- If "call do_nothing ( row(Ind) )" is replaced by "call do_nothing ( row(2:3)
)" the issue goes away. 
- It also goes away if the allocatable component ("col") is replaced by a fixed
sized one (e.g. col(4))
- The problem seems to be dependent of the OS. For example, it doesn't occur on
linux (even with an old version of gfortran: 4.8.5). (For some additional
details about this point, please see the answers to my question on
stackoverflow
(https://stackoverflow.com/questions/53839760/passing-a-portion-of-an-array-of-a-derived-type-that-contains-an-allocatable-com).
 

Best Regards.

[Bug target/65146] alignment of _Atomic structure member is not correct

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  ---
And the post has appeared now, which didn't happen last time.

[Bug target/65146] alignment of _Atomic structure member is not correct

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
Submitted, subject "Alignment requirements for _Atomic should be stated"

[Bug target/87237] __atomic_load on 4-byte-sized, 1-byte-aligned struct is not atomic

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
c.f. Bug 65146

[Bug target/86487] [7/8/9 Regression] insn does not satisfy its constraints on arm big-endian

[avieira at gcc dot gnu.org]

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

--- Comment #7 from avieira at gcc dot gnu.org ---
Hi,

This one sort of fell through the cracks on me. With help from Vlad and Richard
S. I managed to track the issue to uses_hard_regs_p and the way it handles
paradoxical subregs (or fails to). I have a patch for this, which I will rebase
and test.  Ill give your new testcase a whirl Oliver thanks!

Cheers,
Andre

[Bug target/65146] alignment of _Atomic structure member is not correct

[hjl.tools at gmail dot com]

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

--- Comment #15 from H.J. Lu  ---
(In reply to Jonathan Wakely from comment #14)
> I'm subscribed as abusenet at kayari dot org and I'm pretty sure that's the
> address I used for both posts, because that's what the Google web UI does
> automatically.

Sorry for the mishap. Can you send it again and let me know when you did?

[Bug target/65146] alignment of _Atomic structure member is not correct

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
I'm subscribed as abusenet at kayari dot org and I'm pretty sure that's the
address I used for both posts, because that's what the Google web UI does
automatically.

[Bug target/88213] ICE in change_address_1, at emit-rtl.c:2286

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #9 from Segher Boessenkool  ---
Fixed (on trunk, 8 and 7).

[Bug libstdc++/65675] make bootstrap fails when configured with --disable-hosted-libstdcxx

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
The change in comment 5 was done in r222542

[Bug target/65146] alignment of _Atomic structure member is not correct

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu  ---
(In reply to Jonathan Wakely from comment #12)
> (In reply to Jonathan Wakely from comment #11)
> > (In reply to Jonathan Wakely from comment #9)
> > > Did this ever get taken to the ABI group?
> > 
> > I've done so now.
> 
> I tried to start a discussion at the ia32-abi group, twice, but the
> moderator never approved them. At this point I no longer care enough to keep
> trying.

There is no pending message at

https://groups.google.com/forum/#!forum/ia32-abi

Which email address were you using to send email to ia32-abi?  You
need to send email from the email address you used to subscribe
ia32-abi.

[Bug target/88213] ICE in change_address_1, at emit-rtl.c:2286

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
Author: segher
Date: Wed Dec 19 14:04:22 2018
New Revision: 267265

URL: https://gcc.gnu.org/viewcvs?rev=267265=gcc=rev
Log:
Backport from trunk
2018-12-19  Segher Boessenkool  

PR target/88213
* config/rs6000/vsx.md (*vsx_extract___load):
Require TARGET_POWERPC64.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/vsx.md

[Bug c++/87841] Member of class template hides template parameter of another member

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
I've asked the C++ committee to clarify whether the example is bogus or not.

[Bug target/88213] ICE in change_address_1, at emit-rtl.c:2286

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
Author: segher
Date: Wed Dec 19 14:02:52 2018
New Revision: 267264

URL: https://gcc.gnu.org/viewcvs?rev=267264=gcc=rev
Log:
Backport from trunk
2018-12-19  Segher Boessenkool  

PR target/88213
* config/rs6000/vsx.md (*vsx_extract___load):
Require TARGET_POWERPC64.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/rs6000/vsx.md

[Bug target/83443] FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 119)

[samtebbs at gcc dot gnu.org]

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

samtebbs at gcc dot gnu.org changed:

   What|Removed |Added

 CC||samtebbs at gcc dot gnu.org

--- Comment #3 from samtebbs at gcc dot gnu.org ---
These failures are still occurring as

FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c second (test for warnings, line
120)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c second (test for warnings, line
122)

on arm-none-linux-gnueabihf

r266743 renamed the tests from "" to "second" and r263612 pushed them both down
a line. Is there any any plan to address this?

[Bug c++/87999] Constexpr eval. in static_assert makes string_view comparison non constexpr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-19
  Component|libstdc++   |c++
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
This seems like a compiler bug not a library one.

[Bug target/88213] ICE in change_address_1, at emit-rtl.c:2286

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Author: segher
Date: Wed Dec 19 13:54:08 2018
New Revision: 267263

URL: https://gcc.gnu.org/viewcvs?rev=267263=gcc=rev
Log:
Restrict a VSX extract to TARGET_POWERPC64 (PR88213)

This pattern optimises a scalar extract from a vector loaded from
memory to be just a scalar load from memory.  But to do a 64-bit
integer load you need 64-bit integer registers, which needs
TARGET_POWERPC64.


PR target/88213
* config/rs6000/vsx.md (*vsx_extract___load):
Require TARGET_POWERPC64.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/vsx.md

[Bug c++/80990] cv-qualifiers ignored in variable definition using class template argument deduction

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
I no longer plan to backport this.

[Bug target/65146] alignment of _Atomic structure member is not correct

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Jonathan Wakely from comment #9)
> > Did this ever get taken to the ABI group?
> 
> I've done so now.

I tried to start a discussion at the ia32-abi group, twice, but the moderator
never approved them. At this point I no longer care enough to keep trying.

[Bug bootstrap/84257] Extremely slow compilation from gcc source code under macOS 10.13

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #5)

> 1) Speculation: that there are a lot of paths to search and they might
> contain many files, so that if there's no caching of the results (perhaps
> that was present pre-SIP and is now removed) .. it could mean a lot of work
> to find the libgcc_s - that's the last path in the list.  
> 
>  * To test this hypothesis, I'm going to experiment with re-ordering the
> search path (temporary fix).

So some experiments

 * average GCC build time difference (loaded machine, 80% of threads in use) -
3:1

 * variation is quite high - from 3:1 - 20:1 if one just does a single
configure operation repeatedly (I speculate that when dyld is busy, then things
slow down).

 * Removing all but the GCC path, more or less behaves the same as an empty
DYLD_LIBRARY_PATH

 * However, simply re-ordering the paths doesn't seem to be effective, so I
speculate that it's the process of searching the paths for libs that are _not_
found (and therefore then picked up from their usual place) that's the time
sink

[Bug c/88544] ICE on ARM Cortex A7

[ynezz at true dot cz]

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

--- Comment #3 from Petr Štetiar  ---
Hi Richard,

thanks a lot for your fast response!

It's probably my first bug report to GCC so I'll probably need a little
guidance to get you output which might help you.

I can do or enable whatever is needed, even apply patches to GCC to help
tracking down and fix this issue. For the start I'll enable coredumps as you've
suggested, meanwhile I've found one log with the first ICE (different platform
cortex-a15) encountered, but I didn't paid much attention to it at that time.

CC  drivers/net/ethernet/freescale/sdk_dpaa/mac-api.o
In file included from ./include/linux/device.h:16:0,
 from ./include/linux/of_platform.h:14,
 from drivers/net/ethernet/freescale/sdk_dpaa/mac-api.c:44:
./include/linux/ioport.h:26:1: internal compiler error: Segmentation fault
 };
 ^
0x9e090f crash_signal
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/toplev.c:337
0x102f528 _cpp_process_line_notes
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/lex.c:1165
0x102f650 _cpp_skip_block_comment
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/lex.c:1224
0x103255c _cpp_lex_direct
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/lex.c:2818
0x1036134 lex_expansion_token
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/macro.c:3029
0x1039540 create_iso_definition
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/macro.c:3201
0x1039540 _cpp_create_definition
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/macro.c:3277
0x1023801 do_define
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/directives.c:644
0x1024fcf _cpp_handle_directive
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/directives.c:547
0x1032f2c _cpp_lex_token
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/lex.c:2566
0x1038ecf cpp_get_token_1
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/libcpp/macro.c:2523
0x618c8e c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/c-family/c-lex.c:398
0x5b5410 c_lex_one_token
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/c/c-parser.c:251
0x5d95c2 c_parser_peek_token  
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/c/c-parser.c:435
0x5d95c2 c_parser_next_token_is
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/c/c-parser.h:161
0x5d95c2 c_parser_next_token_is_not
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/c/c-parser.h:170
0x5d95c2 c_parser_translation_unit
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/c/c-parser.c:1346
0x5d95c2 c_parse_file()
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/c/c-parser.c:18183
0x61e992 c_common_parse_file()
   
/home/petr/testing/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.4.0_musl_eabi/gcc-7.4.0/gcc/c-family/c-opts.c:1161
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[10]: *** [drivers/net/ethernet/freescale/sdk_dpaa/mac-api.o] Error 1

[Bug c++/88550] New: A compiler error when use lto: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:155

[harrywong at live dot com]

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

Bug ID: 88550
   Summary: A compiler error when use lto: internal compiler
error: in add_symbol_to_partition_1, at
lto/lto-partition.c:155
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: harrywong at live dot com
  Target Milestone: ---

Recently I try to switch my project from GCC 7 to GCC 8, but when linking, it
turned out this error:

to1: internal compiler error: in add_symbol_to_partition_1, at
lto/lto-partition.c:155
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: fatal error: /usr/bin/g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

Here's my GCC version:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-12'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-12) 

Here'e my compiler flags:
-O3 -fuse-linker-plugin -flto -ffat-lto-objects

It compiled well when using GCC 7.x series.

[Bug c++/88196] [9 Regression] ICE on (invalid) C++ code when compiled with -std=c++2a: in convert_nontype_argument, at cp/pt.c:7137

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org

--- Comment #2 from Alexandre Oliva  ---
Mine

[Bug tree-optimization/88533] [9 Regression] Higher performance penalty of array-bounds checking for sparse-matrix vector multiply

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/88146] ice in tsubst_copy, at cp/pt.c:16014

[aoliva at gcc dot gnu.org]

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

Bug 87814 Summary: [9 Regression] ICE in in tsubst_copy, at cp/pt.c:15962 with 
range-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87814

   What|Removed |Added

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

[Bug c++/87814] [9 Regression] ICE in in tsubst_copy, at cp/pt.c:15962 with range-v3

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #9 from Alexandre Oliva  ---
Fixed

[Bug c++/88180] [7/8/9 Regression] ICE in vec::quick_push(tree_node* const&)

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #3 from Alexandre Oliva  ---
Created attachment 45263
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45263=edit
candidate patch

Jakub, my 'Mine' comment got a mid-air collision with your proposed patch that
I didn't notice immediately.  Here's what I was testing...

[Bug target/88547] missed optimization for vector comparisons

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
More complete testcase:
typedef signed char v16qi __attribute__((vector_size(16)));
typedef unsigned char v16uqi __attribute__((vector_size(16)));
typedef short v8hi __attribute__((vector_size(16)));
typedef unsigned short v8uhi __attribute__((vector_size(16)));
typedef int v4si __attribute__((vector_size(16)));
typedef unsigned v4usi __attribute__((vector_size(16)));
typedef long long v2di __attribute__((vector_size(16)));
typedef unsigned long long v2udi __attribute__((vector_size(16)));

v16qi
f1 (v16qi x, v16qi y)
{
  return x <= y;
}

v16qi
f1a (v16qi x, v16qi y)
{
  return x < y;
}

v16uqi
f2 (v16uqi x, v16uqi y)
{
  return x <= y;
}

v16qi
f3 (v16qi x, v16qi y)
{
  return x >= y;
}

v16uqi
f4 (v16uqi x, v16uqi y)
{
  return x >= y;
}

v8hi
f5 (v8hi x, v8hi y)
{
  return x <= y;
}

v8uhi
f6 (v8uhi x, v8uhi y)
{
  return x <= y;
}

v8hi
f7 (v8hi x, v8hi y)
{
  return x >= y;
}

v8uhi
f8 (v8uhi x, v8uhi y)
{
  return x >= y;
}

v4si
f9 (v4si x, v4si y)
{
  return x <= y;
}

v4usi
f10 (v4usi x, v4usi y)
{
  return x <= y;
}

v4si
f11 (v4si x, v4si y)
{
  return x >= y;
}

v4usi
f12 (v4usi x, v4usi y)
{
  return x >= y;
}

v2di
f13 (v2di x, v2di y)
{
  return x <= y;
}

v2udi
f14 (v2udi x, v2udi y)
{
  return x <= y;
}

v2di
f15 (v2di x, v2di y)
{
  return x >= y;
}

v2udi
f16 (v2udi x, v2udi y)
{
  return x >= y;
}

plus of course we need a 32-byte and 64-byte vector variant, and test with
-msse4.1 (the first one to have pmin{s,u}b, -mavx, -mavx2, -mavx512*.

I think it could be done in ix86_expand_int_sse_cmp or in ix86_expand_int_vcond
- perhaps only for the cases where one of the vcond operands is all ones and
the other one is zero, notice that depending on which one is which the negation
is 2 instructions (though, only if we don't hoist the constant load e.g. before
a loop) and that for TARGET_SSE4_1 we can use the minimum or maximum.

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

[glisse at gcc dot gnu.org]

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

--- Comment #14 from Marc Glisse  ---
(In reply to Jeffrey A. Law from comment #12)
> Whether or not to fix as well as whether or not to warn at -O0 are a topic
> of debate.  I'm not sure I'm up for re-opening that can of worms right now.

I think we can both work on reducing false positives and move it out of -Wall,
it isn't exclusive.

> I strongly believe -Wmaybe-uninitialized should continue to be enabled by
> -Wall.   They tend to either point out obscure ways objects are
> uninitialized or they point out missed optimizations.  Both are critical in
> my mind.

-Wall
   This enables all the warnings about constructions that some users
   consider questionable, and that are easy to avoid (or modify to
   prevent the warning), even in conjunction with macros.

I don't see how you can ever satisfy the "easy to avoid" part. In my experience
with several code bases, having this warning in -Wall (as opposed to -Wextra)
does more harm than good, with people doing random bad code changes to try and
get the compiler to shut up.

I still believe this warning is a very useful static analysis tool (I
contributed to make it appear more often in the past), but by definition it
will never avoid false positives.

[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)

[rguenth at gcc dot gnu.org]

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

--- Comment #35 from Richard Biener  ---
Author: rguenth
Date: Wed Dec 19 11:10:08 2018
New Revision: 267262

URL: https://gcc.gnu.org/viewcvs?rev=267262=gcc=rev
Log:
2018-12-19  Richard Biener  

PR tree-optimization/88533
Revert
2018-04-30  Richard Biener  

PR tree-optimization/28364
PR tree-optimization/85275
* tree-ssa-loop-ch.c (ch_base::copy_headers): Stop after
copying first exit test.

* gcc.dg/tree-ssa/ssa-dom-thread-7.c: Adjust.

* tree-ssa-loop-ch.c: Include tree-phinodes.h and
ssa-iterators.h.
(should_duplicate_loop_header_p): Track whether stmt compute
loop invariants or values based on IVs.  Apart from the
original loop header only duplicate blocks with exit tests
that are based on IVs or invariants.

* gcc.dg/tree-ssa/copy-headers-6.c: New testcase.
* gcc.dg/tree-ssa/copy-headers-7.c: Likewise.
* gcc.dg/tree-ssa/ivopt_mult_1.c: Un-XFAIL.
* gcc.dg/tree-ssa/ivopt_mult_2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c
trunk/gcc/tree-ssa-loop-ch.c

[Bug tree-optimization/88533] [9 Regression] Higher performance penalty of array-bounds checking for sparse-matrix vector multiply

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Wed Dec 19 11:10:08 2018
New Revision: 267262

URL: https://gcc.gnu.org/viewcvs?rev=267262=gcc=rev
Log:
2018-12-19  Richard Biener  

PR tree-optimization/88533
Revert
2018-04-30  Richard Biener  

PR tree-optimization/28364
PR tree-optimization/85275
* tree-ssa-loop-ch.c (ch_base::copy_headers): Stop after
copying first exit test.

* gcc.dg/tree-ssa/ssa-dom-thread-7.c: Adjust.

* tree-ssa-loop-ch.c: Include tree-phinodes.h and
ssa-iterators.h.
(should_duplicate_loop_header_p): Track whether stmt compute
loop invariants or values based on IVs.  Apart from the
original loop header only duplicate blocks with exit tests
that are based on IVs or invariants.

* gcc.dg/tree-ssa/copy-headers-6.c: New testcase.
* gcc.dg/tree-ssa/copy-headers-7.c: Likewise.
* gcc.dg/tree-ssa/ivopt_mult_1.c: Un-XFAIL.
* gcc.dg/tree-ssa/ivopt_mult_2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c
trunk/gcc/tree-ssa-loop-ch.c

[Bug tree-optimization/85275] copyheader peels off almost the entire iteration

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Dec 19 11:10:08 2018
New Revision: 267262

URL: https://gcc.gnu.org/viewcvs?rev=267262=gcc=rev
Log:
2018-12-19  Richard Biener  

PR tree-optimization/88533
Revert
2018-04-30  Richard Biener  

PR tree-optimization/28364
PR tree-optimization/85275
* tree-ssa-loop-ch.c (ch_base::copy_headers): Stop after
copying first exit test.

* gcc.dg/tree-ssa/ssa-dom-thread-7.c: Adjust.

* tree-ssa-loop-ch.c: Include tree-phinodes.h and
ssa-iterators.h.
(should_duplicate_loop_header_p): Track whether stmt compute
loop invariants or values based on IVs.  Apart from the
original loop header only duplicate blocks with exit tests
that are based on IVs or invariants.

* gcc.dg/tree-ssa/copy-headers-6.c: New testcase.
* gcc.dg/tree-ssa/copy-headers-7.c: Likewise.
* gcc.dg/tree-ssa/ivopt_mult_1.c: Un-XFAIL.
* gcc.dg/tree-ssa/ivopt_mult_2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c
trunk/gcc/tree-ssa-loop-ch.c

[Bug fortran/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin

[paul.richard.thomas at gmail dot com]

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

--- Comment #18 from paul.richard.thomas at gmail dot com  ---
Exactly

On Wed, 19 Dec 2018 at 09:17, jakub at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881
>
> --- Comment #17 from Jakub Jelinek  ---
> The multiple REF_INQUIRY allowed is just whatever%re%kind or whatever%im%kind,
> right (because %re/%im must apply to complex and makes a scalar out of it and
> %len needs a character type designator)?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug c++/88180] [7/8/9 Regression] ICE in vec::quick_push(tree_node* const&)

[jakub at gcc dot gnu.org]

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

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 45262
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45262=edit
gcc9-pr88180.patch

Untested fix.

[Bug target/86487] [7/8/9 Regression] insn does not satisfy its constraints on arm big-endian

[oliver.stannard at arm dot com]

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

Oliver Stannard  changed:

   What|Removed |Added

 CC||oliver.stannard at arm dot com

--- Comment #6 from Oliver Stannard  ---
I've found a simpler reproducer for the same crash, this one uses a NEON type,
and affects little-endian as well as big-endian:

// test.c
#include 
int32x2_t b(long c, ...) {}

$ arm-none-eabi-gcc -march=armv7-a -c test.c -mfloat-abi=hard -mfpu=neon 
test.c: In function 'b':
test.c:1:1: error: insn does not satisfy its constraints:
1 | __simd64_int32_t b(long c, ...) {}
  | ^~~~
(insn 6 11 9 2 (set (reg/i:V2SI 0 r0)
(reg:V2SI 2 r2 [orig:110  ] [110])) "test.c":1:1 939
{*neon_movv2si}
 (nil))
during RTL pass: reload
test.c:1:1: internal compiler error: in extract_constrain_insn, at recog.c:2206
0xbaf641 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/tmp/dgboter/bbs/rhev-vm1--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/rtl-error.c:108
0xbaf672 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/tmp/dgboter/bbs/rhev-vm1--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/rtl-error.c:119
0xb82846 extract_constrain_insn(rtx_insn*)
   
/tmp/dgboter/bbs/rhev-vm1--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/recog.c:2206
0xa6fa52 check_rtl
   
/tmp/dgboter/bbs/rhev-vm1--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/lra.c:2182
0xa74166 lra(_IO_FILE*)
   
/tmp/dgboter/bbs/rhev-vm1--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/lra.c:2616
0xa2a224 do_reload
   
/tmp/dgboter/bbs/rhev-vm1--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/ira.c:5469
0xa2a224 execute
   
/tmp/dgboter/bbs/rhev-vm1--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/ira.c:5653
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/84362] [7/8/9 Regression] Auto-vectorization regression when accessing member variable through getter/accessor

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Created attachment 45261
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45261=edit
patch I am testing

I am testing the attached.

[Bug bootstrap/84257] Extremely slow compilation from gcc source code under macOS 10.13

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #5 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #4)
> Confirmed even if I recover only a factor 2.

Unfortunately, neither SIP's ignoring - nor removing RPATH_ENVVAR - produces
the intended result.

Quoting from the Makefile 
"
# This is the list of directories that may be needed in RPATH_ENVVAR
# so that programs built for the target machine work.
TARGET_LIB_PATH =

# This is the list of directories that may be needed in RPATH_ENVVAR
# so that programs built for the host machine work.
HOST_LIB_PATH =
"

> I don't think setting RPATH_ENVVAR to DYLD_LIBRARY_PATH is necessary on 
> modern macOS > versions, please check.

The requirement has nothing to do with 'modern' c.f. 'old' macOS/Darwin; these
paths are intended to ensure that the correct (just-built, or even not present
in the system installation) libraries are available to the stage#1 target
libraries build and stage#2+ where needed.  For most people's "usual" build the
compiler is statically linked with libstdc++  and so this really only
affects configure steps when the new compiler is generating code that _should_
use the newly-built support libs.

When SIP is enabled (or when you remove the DYLD_LIBRARY_PATH setting) we have
been "getting away" falling back to system versions of libstdc++ and libgcc_s.x
... this doesn't work if one introduces a new lib that isn't present on the
system (which I want to do to solve the long-standing hassles with the
unwinder).

* As an aside, there is no Good Solution to using DYLD_LIBRARY_PATH - if it's
exported at the top level, since it must be honoured for *every* exe that runs
below this, which means that it also affects system-utils (e.g. ld).. this has
been a source of instability on occasion.

So.. what to do?

We don't (well I don't) really want to be forced to switch SIP off to build
toolchains, but OTOH it's necessary to manipulate the library load ordering
when building a toolchain

1) Speculation: that there are a lot of paths to search and they might contain
many files, so that if there's no caching of the results (perhaps that was
present pre-SIP and is now removed) .. it could mean a lot of work to find the
libgcc_s - that's the last path in the list.  

 * To test this hypothesis, I'm going to experiment with re-ordering the search
path (temporary fix).

2) A possible proper fix is to make use of @rpath/ and set appropriate rpaths
in the build.  A while ago I was experimenting with this to solve some of our
general deployment issues
 * will look out those patches.

3) We could (probably) abandon the shared libgcc_ext lib, after some patches in
progress to eliminate the unwinder hassles.  This would hide (most) of the
problem, but not really solve it.
  * I can easily try this.

1 and 3 are, of course, the easier options (they paper over cracks for the
short-term) - but 2 might be quite tricky to get right (it has to work in the
build layout _and_ when installed).

4) I did think that we could perhaps move all built host libs to a Known Place
in the build tree [e.g. $(builddir)/host-libs, prev-host-libs] (likewise target
libs, to a separate Known Place).  That would mean a reduced number of paths to
search, and that path would only have the libs - not thousands of other files
too.  That's probably quite a bit of build/test system hacking tho ..

[Bug tree-optimization/88464] AVX-512 vectorization of masked scatter failing with "not suitable for scatter store"

[jakub at gcc dot gnu.org]

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

--- Comment #28 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #27)
> (In reply to Jakub Jelinek from comment #25)
> > Isn't ktestw and kortestw the same thing when both operands are the same
> > mask register?
> True, but kortestw is available with AVX512F, where ktestw is not.
> 
> (In reply to Jakub Jelinek from comment #26)
> > And the TARGET_AVX512F &&  looks incorrect, then we wouldn't be able to test
> > or cmp without -mavx512f.
> No, we fall to *cmp_ccno_1, which is compatible with CCZmode.

You're right, sorry for the noise.  Your patch looks good to me.

There is another issue though (I guess not correctness, but efficiency), e.g.
on avx512vl-pr88464-{1,3}.c.
E.g. in avx512vl-pr88464-3.c we have:
  if (mask__40.16_82 == { 0, 0 })
goto ; [100.00%]
  else
goto ; [20.00%]
in *.optimized, an attempt to jump around masked stores if the mask is all
zeros.

We emit:
;; if (mask__40.16_82 == { 0, 0 })

(insn 44 43 45 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:QI 131 [ mask__40.16 ])
(const_int 0 [0]))) -1
 (nil))

(jump_insn 45 44 0 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 0)
(pc))) -1
 (int_list:REG_BR_PROB 1073741831 (nil)))
for this, i.e.
kmovw   %k2, %r10d
testb   %r10b, %r10b
je  .L4
(without -mavx512dq, I guess ktestb or kortestb with -mavx512dq), but perhaps
we should emit kmovw %k2, %r10d; testb $3, %r10b; je .L4 instead?
If the setter is a compare that clears the higher bit, then it makes no
difference, but if we are e.g. looking at the low 2 or 4 bits of 4 or 8 bit
mask, then it will do a masked store even if the 2 or 4 bits we care about are
clear, just some upper bits are not.

[Bug tree-optimization/88464] AVX-512 vectorization of masked scatter failing with "not suitable for scatter store"

[ubizjak at gmail dot com]

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

--- Comment #27 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #25)
> Isn't ktestw and kortestw the same thing when both operands are the same
> mask register?
True, but kortestw is available with AVX512F, where ktestw is not.

(In reply to Jakub Jelinek from comment #26)
> And the TARGET_AVX512F &&  looks incorrect, then we wouldn't be able to test
> or cmp without -mavx512f.
No, we fall to *cmp_ccno_1, which is compatible with CCZmode.

[Bug target/88535] sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #11 from john henning  ---
>> There are 3 different switches: --build, --host and --target.
>
> Hmm.  I must be looking in the wrong place for documentation; are these
> explained somewhere?  
>
> At https://gcc.gnu.org/install/configure.html I see a description of 
>--target
> and a brief mention of 
>--host
> but no definition.  There doesn't seem to be a description for --build.

That's because all three are common configure switches, thus described
in the autoconf manual.

If none is given, config.guess tries it's best to determine them.
Otherwise, the --host value defaults to the --build one if not given
explicitly, and likewise --target to --host.

I've seen cases (don't remember the details) when this didn't work as
expected, so I tend to pass all three to avoid trouble (like configure
configure wrongly assuming it's a cross build when in fact it's a native
one).

[Bug target/88541] VPCLMULQDQ 256-bit inline function unavailable with optimization but without enabled AVX512VL support

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Because AVX was what is in i386-builtins.def already and as the testcase shows,
it works with just -mavx.  You can not just load/store those vectors, you can
also do logical operations on them etc. (through the floating point vector
ops).
With GFNI I believe the point was that the corresponding mode wasn't allowed in
the registers without SSE2, so you'd get ICEs.

[Bug target/88541] VPCLMULQDQ 256-bit inline function unavailable with optimization but without enabled AVX512VL support

[jbeulich at novell dot com]

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

--- Comment #5 from jbeulich at novell dot com ---
So why -mavx instead of -mavx2? I think the way it was done for GFNI and SSE2
it should also be done there, here and for VAES wrt AVX: Only SSE2 provides
support for vectors of ints. Similarly only AVX2 provides supports for 256-bit
vectors of ints. Exceptions in both cases are that it is (in principle)
possible to load/store such vectors.

[Bug tree-optimization/88464] AVX-512 vectorization of masked scatter failing with "not suitable for scatter store"

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek  ---
And the TARGET_AVX512F &&  looks incorrect, then we wouldn't be able to test or
cmp without -mavx512f.

[Bug tree-optimization/88464] AVX-512 vectorization of masked scatter failing with "not suitable for scatter store"

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek  ---
Isn't ktestw and kortestw the same thing when both operands are the same mask
register?