[Bug c++/82790] New: [GCC 5, 6, 7] -Wuseless-cast doesn't detect unnecessary removal of const

[eugene.zelenko at gmail dot com]

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

Bug ID: 82790
   Summary: [GCC 5, 6, 7] -Wuseless-cast doesn't detect
unnecessary removal of const
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eugene.zelenko at gmail dot com
  Target Milestone: ---

[GCC 5, 6, 7] -Wuseless-cast doesn't detect unnecessary removal of const.

For example:

static void Function(const char *Parameter) {
}

static void Caller() {
  const char *Variable = "String";

  Function( const_cast( Variable ) );
  Function( (char *) Variable );
}

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[brycm001 at gmail dot com]

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

--- Comment #14 from Matti Bryce  ---
(In reply to Martin Liška from comment #12)
> (In reply to Matti Bryce from comment #7)
> > (In reply to Martin Liška from comment #5)
> > > Confirmed with cross compiler, I reduce a test-case.
> > 
> > I've attempted to reduce a test case, but after 2 days of running creduce,
> > the produced file won't generate the error.
> 
> Hi. Looks you hit stack overflow. In that case, please use ulimit and set
> smaller stack, that will simplify the reduction. You have to properly write
> creduce script that will catch the ICE:
> https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
> 
> And please use -fmax-errors=1 which will guarantee that reduced test-case
> will be a valid code.
> 
> Please either download debug symbols for GCC package. Or build your own from
> source: https://gcc.gnu.org/install/configure.html
> 
> Feel free to ask for questions..

There are no debug symbols available, so I'm going to have to build gcc. But I
can't find the configure option on https://gcc.gnu.org/install/configure.html,
so if you could tell me the flag to use to enable debug symbols, that would be
helpful. 

I'm running creduce again, so I'll get back to you on that once it has finished
running.

Thanks.

Thanks.

[Bug c/79696] missing -Wunused-result on calls to malloc() and calloc()

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2017-07-31 00:00:00 |2017-10-31
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
(In reply to Martin Sebor from comment #3)
> Whoops.  The test case is below.  Also, the calls to the functions are only
> eliminated with optimization.  Otherwise they're emitted and the leaks
> allowed to go undetected.  (For some reason I don't understand, Glibc only
> also marks functions warn_unused_result with _FORTIFY_SOURCE, otherwise its
> __wur macro that's used for this purpose expands to nothing.)
> 
> $ cat a.c && gcc -S -Wall -Wextra -Wpedantic
> -fdump-tree-optimized=/dev/stdout a.c
> void f (unsigned n)
> {
>   __builtin_malloc (n);
> }
> 
> void g (unsigned n)
> {
>   __builtin_calloc (n, n);
> }
> 
> void h (unsigned n)
> {
>   __builtin_aligned_alloc (n, 2);
> }
> 
> ;; Function f (f, funcdef_no=2, decl_uid=2364, cgraph_uid=2, symbol_order=2)
> 
> f (unsigned int n)
> {
>   long unsigned int _1;
> 
>[0.00%] [count: INV]:
>   _1 = (long unsigned int) n_2(D);
>   __builtin_malloc (_1);
>   return;
> 
> }
> 
> 
> 
> ;; Function g (g, funcdef_no=3, decl_uid=2367, cgraph_uid=3, symbol_order=3)
> 
> g (unsigned int n)
> {
>   long unsigned int _1;
>   long unsigned int _2;
> 
>[0.00%] [count: INV]:
>   _1 = (long unsigned int) n_3(D);
>   _2 = (long unsigned int) n_3(D);
>   __builtin_calloc (_2, _1);
>   return;
> 
> }
> 
> 
> 
> ;; Function h (h, funcdef_no=4, decl_uid=2370, cgraph_uid=4, symbol_order=4)
> 
> h (unsigned int n)
> {
>   long unsigned int _1;
> 
>[0.00%] [count: INV]:
>   _1 = (long unsigned int) n_2(D);
>   __builtin_aligned_alloc (_1, 2);
>   return;
> 
> }

Confirmed, although the optimized output is slightly different for me:

$ /usr/local/bin/gcc -c -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout 79696.c

;; Function f (f, funcdef_no=0, decl_uid=1769, cgraph_uid=0, symbol_order=0)

f (unsigned int n)
{
   [0.00%] [count: INV]:
  __builtin_malloc (n_2(D));
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1772, cgraph_uid=1, symbol_order=1)

g (unsigned int n)
{
   [0.00%] [count: INV]:
  __builtin_calloc (n_2(D), n_2(D));
  return;

}



;; Function h (h, funcdef_no=2, decl_uid=1775, cgraph_uid=2, symbol_order=2)

h (unsigned int n)
{
   [0.00%] [count: INV]:
  __builtin_aligned_alloc (n_2(D), 2);
  return;

}


$

[Bug other/82590] auto-host.h error: declaration does not declare anything

[bastl at eclipso dot de]

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

--- Comment #1 from bastl  ---
Compiling gcc-7.2.0 with gcc-7.2.0
works fine.
What I did on this error and the other errors followed:
comment out the definitions cousing the errors like:

1.)
gcc/system.h:496:14: error: ambiguating new declaration of 'char* strstr(const
char*, const char*)'
 extern char *strstr (const char *, const char *);

2.)
gcc/system.h:540:20: error: conflicting declaration of C function 'const char*
strsignal(int)'
 extern const char *strsignal (int);
in the source directory in:

3.)
include/libiberty.h:112:14: error: ambiguating new declaration of 'char*
basename(const char*)'
 extern char *basename (const char *) ATTRIBUTE_RETURNS_NONNULL
ATTRIBUTE_NONNULL(1);

4.)
gcc/timevar.c:28:13: error: conflicting declaration 'typedef int clock_t'
 typedef int clock_t;

5.)
gcc/timevar.c:32:8: error: redefinition of 'struct tms'
 struct tms

then

# make -i

because all other errors don't matter to have a working gcc-7.2.0 compiler that
can compile itself.

# make -i install

and remake gcc itself.

[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233

[dansan at gcc dot gnu.org]

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

--- Comment #9 from dansan at gcc dot gnu.org ---
Author: dansan
Date: Tue Oct 31 21:48:55 2017
New Revision: 254284

URL: https://gcc.gnu.org/viewcvs?rev=254284=gcc=rev
Log:
PR target/82002 Part 1: Correct ICE caused by wrong calculation

gcc:
config/i386/i386.c (ix86_expand_epilogue): Correct stack
calculation.

gcc/testsuite:
gcc.target/i386/pr82002-1.c: New test.
gcc.target/i386/pr82002-2a.c: New xfail test.
gcc.target/i386/pr82002-2b.c: New xfail test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr82002-1.c
trunk/gcc/testsuite/gcc.target/i386/pr82002-2a.c
trunk/gcc/testsuite/gcc.target/i386/pr82002-2b.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/81702] [7/8 Regression] ICE in gimple_get_virt_method_for_vtable

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Jambor  ---
Fixed on trunk, testing on gcc-7-branch in progress.

[Bug c++/81702] [7/8 Regression] ICE in gimple_get_virt_method_for_vtable

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  ---
Author: jamborm
Date: Tue Oct 31 21:36:51 2017
New Revision: 254283

URL: https://gcc.gnu.org/viewcvs?rev=254283=gcc=rev
Log:
[PR 81702] Remove devirtualization assert

2017-10-31  Martin Jambor  

PR c++/81702
* gimple-fold.c (gimple_get_virt_method_for_vtable): Remove assert.

testsuite/
* g++.dg/tree-ssa/pr81702.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr81702.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug libgcc/82635] std::thread's join broken on FreeBSD with all GCCs >= 5

[andreast at gcc dot gnu.org]

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

--- Comment #12 from Andreas Tobler  ---
Will soon commit a fix, for gcc6/7/8 on FreeBSD > 9.3. Older gcc's and OS
releases will not be supported by this fix.

[Bug target/82333] [8 Regression] powerpc64le _Float128 ICE in as_a, at machmode.h:345

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
This occurs because both fld and ff128 return the same constant (0), one using
it as a long double and the other as a _Float128.  Having a 0 constant is not
important.  If we return 1 in both functions, it will still trap.

If we change the constant so each function (fld and ff128) returns a different
value, it works.

If we suppress inlining, it works.

[Bug c++/82789] Invalid code generated for std::array element-wise processing with -O3

[nazarenkoal at gmail dot com]

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

--- Comment #1 from Alexander Nazarenko  ---
(In reply to Alexander Nazarenko from comment #0)
Minor correction:
In code must be:

template 
A l_and_r( A const l, A const r )

[Bug c++/82789] New: Invalid code generated for std::array element-wise processing with -O3

[nazarenkoal at gmail dot com]

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

Bug ID: 82789
   Summary: Invalid code generated for std::array element-wise
processing with -O3
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nazarenkoal at gmail dot com
  Target Milestone: ---

Version:
$ gcc --version
gcc (Ubuntu 7.2.0-8ubuntu3) 7.2.0

Not reproduced on:
gcc-6 (Ubuntu 6.4.0-8ubuntu1) 6.4.0 20171010
gcc-5 (Ubuntu 5.5.0-1ubuntu1) 5.4.1 20171010

OS:
$ lsb_release -a
LSB Version:   
core-9.20160110ubuntu5-amd64:core-9.20160110ubuntu5-noarch:security-9.20160110ubuntu5-amd64:security-9.20160110ubuntu5-noarch
Distributor ID: Ubuntu
Description:Ubuntu 17.10
Release:17.10
Codename:   artful

Commandline:
gcc -DNDEBUG -O3 ./test_opt_2.cpp -o ./test_opt_2 -std=c++14 -lstdc++

Code:
#include 
#include 

template 
A l_and_r( A const & l, A const & r )
{
A res = {0};

for ( unsigned i=0; i

[Bug libstdc++/70129] [6 Regression] stdlib.h: No such file or directory when using -isystem /usr/include

[chuck at ece dot cmu.edu]

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

--- Comment #5 from chuck cranor  ---
I don't think anyone would manually add "-isystem /usr/include" ...
but build systems that provide variables for third party headers that
may or may not be installed in /usr/include often trigger this.

e.g. if boost is installed in prefix /pkg, then you want to include
/pkg/include in the search path.   if boost is installed in /usr
then you want /usr/include in the search path.  if you have 
"-isystem ${BOOST_PREFIX}/include" in your CXXFLAGS and BOOST_PREFIX
happens to be set to /usr somewhere earlier, you lose.


For what it's worth, this definitely crops up in cmake-based builds:

https://gitlab.kitware.com/cmake/cmake/issues/16291

I triggered it with cmake and Boost on a Cray.  It is partly cmake's
fault too.  Its handling of CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES
isn't correct.

[Bug tree-optimization/82788] New: wrong code with -fstack-clash-protection --param=stack-clash-protection-probe-interval=10 on simple code

[zsojka at seznam dot cz]

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

Bug ID: 82788
   Summary: wrong code with -fstack-clash-protection
--param=stack-clash-protection-probe-interval=10 on
simple code
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

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

$ cat testcase.c 
int main() { int a[1442]; }
$ x86_64-pc-linux-gnu-gcc -fstack-clash-protection
--param=stack-clash-protection-probe-interval=10 testcase.c
$ ./a.out 
Segmentation fault

In the assembly, there is a loop that never finishes (until it segfaults):
...
lea r11, [rsp-5120]
.LPSRL0:
sub rsp, 4096
or  DWORD PTR [rsp], 0
cmp rsp, r11
jne .LPSRL0
...


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

[Bug middle-end/82658] Suboptimal codegen on AVR when right-shifting 8-bit unsigned integers.

[mike.k at digitalcarbide dot com]

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

--- Comment #2 from mike.k at digitalcarbide dot com ---
I wanted to validate if this issue was presenting in the toolchains for other
architectures, so I tested a bit:

GCC 7.2.0 on x86-64 (-O3):

C:

movzx   eax, BYTE PTR [rsp-1]
shr al
mov BYTE PTR [rsp-1], al
ret

C++:

movzx   eax, BYTE PTR [rsp-1]
sar eax
mov BYTE PTR [rsp-1], al
ret

While not different in performance, it _is_ generating different code, and the
code difference seems to reflect what Richard already found.

I am not able to reproduce any difference on MIPS64, MIPS32, ARM, ARM64, PPC,
PPC64. This is probably due to backend differences not causing the sequences to
map differently.

I do see it going back to GCC 4.6.4 on AVR.

[Bug libstdc++/70129] [6 Regression] stdlib.h: No such file or directory when using -isystem /usr/include

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Why do you need to use either option? /usr/include is already a system include
dir, so -isystem /usr/include serves no useful purpose.

[Bug libstdc++/70129] [6 Regression] stdlib.h: No such file or directory when using -isystem /usr/include

[chuck at ece dot cmu.edu]

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

chuck cranor  changed:

   What|Removed |Added

 CC||chuck at ece dot cmu.edu

--- Comment #3 from chuck cranor  ---
If the only difference between "-isystem" and "-I" was the change in the
handling of warnings, the #include_next of stdlib.h in libstdc++ would not be
a problem.

The real problem here is that "-isystem /usr/include" changes the include
search path in a way that is incompatible with "-I /usr/include" e.g.

% cat try.cc
#include 
% g++ -c try.cc
% g++ -I /usr/include -c try.cc
% g++ -isystem /usr/include -c try.cc
In file included from try.cc:1:0:
/proj/testbed/data/travis/cache/gcc/include/c++/6.2.0/cstdlib:75:25: fatal
error: stdlib.h: No such file or directory
 #include_next 
 ^
compilation terminated.
% 

I think you'll find most build systems that do "-isystem /usr/include"
instead of "-I /usr/include" are only using "-isystem" for the change
in the warning behavior.  The change in the include path order is not
wanted...

[Bug rtl-optimization/81803] [7/8 regression] miscompilation at -O1 on mips64el

[ebotcazou at gcc dot gnu.org]

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

--- Comment #19 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Oct 31 18:27:52 2017
New Revision: 254275

URL: https://gcc.gnu.org/viewcvs?rev=254275=gcc=rev
Log:
PR rtl-optimization/81803
* lra-constraints.c (curr_insn_transform): Also reload the whole
register for a strict subreg no wider than a word if this is for
a WORD_REGISTER_OPERATIONS target.

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

[Bug target/68192] AIX libstdc++ TLS symbols not exported

[brian at groose dot com]

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

--- Comment #7 from Brian Groose  ---
It turns out I was using binutils' nm when building gcc.  I rebuilt gcc making
sure that only the AIX nm was available, and ld can now find the symbols.

[Bug c/82787] New: gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.13)

[drikosev at gmail dot com]

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

Bug ID: 82787
   Summary: gnu gcc (4.8 - 7.1) cannot parse some system headers
in macOS (10.13)
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drikosev at gmail dot com
  Target Milestone: ---

Hi,

gcc fails to parse various system headers in the latest macOS release (High
Sierra, 10.13).

One of the failures is this:

$ cat syslog.c
#include 
int main() {
 return 0;
}
$ gcc7 syslog.c
In file included from /usr/include/sys/cdefs.h:587:0,
 from /usr/include/sys/syslog.h:65,
 from /usr/include/syslog.h:23,
 from syslog.c:1:
/usr/include/sys/syslog.h:227:124: error: expected ',' or ';' before '__asm'
 void syslog(int, const char *, ...) __printflike(2, 3) __not_tail_called
__DARWIN_ALIAS_STARTING(__MAC_10_13, __IPHONE_NA, __DARWIN_EXTSN(syslog));
   
^
$ gcc7 --version | head -n 1 
gcc7 (GCC) 7.1.1 20170622

Regards,
Ev. Drikos

[Bug ada/82785] [8 Regression] gnat bootstrap fails on m68k-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
.

[Bug ada/82785] [8 Regression] gnat bootstrap fails on m68k-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Oct 31 17:29:26 2017
New Revision: 254274

URL: https://gcc.gnu.org/viewcvs?rev=254274=gcc=rev
Log:
PR ada/82785
* gcc-interface/Makefile.in (m68k/Linux): Fix typo.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/Makefile.in

[Bug c++/82247] [concepts] Name deduction in concepts fails depending on the argument type

[mjklaim at gmail dot com]

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

--- Comment #5 from Joël Lamotte  ---
I'll have to recheck when I have access to a proper computer, but that indeed
would explain this(weird) behavior.
My understanding was that for basic types, ADL would still work using global
namespace, which is why I didn't expect the int case to fail.

[Bug sanitizer/64234] Statically sanitized executable does not export ASan symbols

[ygribov at gcc dot gnu.org]

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

Yury Gribov  changed:

   What|Removed |Added

 CC||ygribov at gcc dot gnu.org

--- Comment #5 from Yury Gribov  ---
Few workarounds for this are listed in
https://stackoverflow.com/questions/46682210/undefined-symbol-error-with-static-libasan/46684596#46684596

[Bug ada/82785] [8 Regression] gnat bootstrap fails on m68k-linux-gnu

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #2 from John Paul Adrian Glaubitz  ---
Thanks Matthias for reporting the issue and thanks Eric for working on it!

[Bug ada/82785] [8 Regression] gnat bootstrap fails on m68k-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-10-31
 CC||ebotcazou at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Typo.

[Bug c/78829] bit-rotten "C99 mode" references in GCC manual

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
_Alignof is alignment requirement (in all contexts), __alignof__ is 
preferred alignment (so on 32-bit x86, for long long they are 4 and 8 
respectively, because a long long in a structure is only 4-byte aligned 
but reducing the result of __alignof__ would have been bad for backwards 
compatibility).

[Bug libstdc++/82777] incorrect result of std::filesystem::path::lexically_normal

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-10-31
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/82786] New: aarch64 frame patch caused a number of target specific test failures.

[sje at gcc dot gnu.org]

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

Bug ID: 82786
   Summary: aarch64 frame patch caused a number of target specific
test failures.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
CC: wdijkstr at arm dot com
  Target Milestone: ---
Target: aarch64-*-*

This patch:

2017-10-26  Wilco Dijkstra  

* config/aarch64/aarch64.c (aarch64_layout_frame):
Ensure LR is always stored at the bottom of the callee-saves.
Remove rarely used frame layout which saves callee-saves at top of
frame, so the store of LR can be used as a valid probe in all cases.

Caused several tests to fail:

FAIL: gcc.target/aarch64/test_frame_10.c scan-assembler ldp\tx19, x30, \\[sp,
[0-9]+\\]
FAIL: gcc.target/aarch64/test_frame_10.c scan-assembler-times stp\tx19, x30,
\\[sp, [0-9]+\\] 1 (found 0 times)
FAIL: gcc.target/aarch64/test_frame_2.c scan-assembler ldp\tx19, x30, \\[sp\\],
[0-9]+
FAIL: gcc.target/aarch64/test_frame_2.c scan-assembler-times stp\tx19, x30,
\\[sp, -[0-9]+\\]! 1 (found 0 times)
FAIL: gcc.target/aarch64/test_frame_4.c scan-assembler ldp\tx19, x30, \\[sp\\],
[0-9]+
FAIL: gcc.target/aarch64/test_frame_4.c scan-assembler-times stp\tx19, x30,
\\[sp, -[0-9]+\\]! 1 (found 0 times)
FAIL: gcc.target/aarch64/test_frame_7.c scan-assembler ldp\tx19, x30, \\[sp\\]
FAIL: gcc.target/aarch64/test_frame_7.c scan-assembler-times stp\tx19, x30,
\\[sp] 1 (found 0 times)

[Bug ada/82785] New: [8 Regression] gnat bootstrap fails on m68k-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 82785
   Summary: [8 Regression] gnat bootstrap fails on m68k-linux-gnu
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with trunk 20171031:

a-dispat.adb:33:06: "System.Linux" is not a predefined library unit
a-dispat.adb:33:06: "Ada.Dispatching (body)" depends on "System.Tasking (spec)"
a-dispat.adb:33:06: "System.Tasking (spec)" depends on "System.Task_Info
(spec)"
a-dispat.adb:33:06: "System.Task_Info (spec)" depends on "System.Os_Interface
(spec)"
a-dispat.adb:33:06: "System.Os_Interface (spec)" depends on "System.Linux
(spec)"
../gcc-interface/Makefile:296: recipe for target 'a-dispat.o' failed
make[9]: *** [a-dispat.o] Error 1
make[9]: Leaving directory
'/home/packages/cross/8/p/gcc-8-cross-ports-0/gcc/build/gcc/ada/rts'
gcc-interface/Makefile:2369: recipe for target 'gnatlib' failed
make[8]: *** [gnatlib] Error 2

[Bug driver/82754] -m32 -B doesn't work with crtn.o

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from H.J. Lu  ---
Works as intended.

[Bug other/82784] Remove semicolon after "do {} while (0)" macros

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
Created attachment 42506
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42506=edit
More minimal asan.c patch

[Bug other/82784] Remove semicolon after "do {} while (0)" macros

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Created attachment 42505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42505=edit
asan.c patch

[Bug c++/82247] [concepts] Name deduction in concepts fails depending on the argument type

[Casey at Carter dot net]

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

Casey Carter  changed:

   What|Removed |Added

 CC||Casey at Carter dot net

--- Comment #4 from Casey Carter  ---
This is not a bug: it's two-phase name lookup. At the point of definition for
Fooable:

#include 
#include 

template 
bool concept Fooable = requires(const T& t) {
{ foo(t) }; // foo is unknown here
};

the compiler records the set of declarations it has seen for "foo" (the empty
set). When you later "instantiate" the concept foo can only resolve to (a) a
member of the (again, empty) set recorded at definition, or (b) a declaration
found by argument-dependent lookup. Since there are no associated namespaces
for fundamental types, only your user-defined type which has a "foo" defined in
its associated namespace successfully concept checks.

[Bug gcov-profile/82702] gcov intermediate format is creating multiple 'gcov' files, it was creating a single file up to GCC 6

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
> We are not using directly lcov, but a replacement we rewrote in Rust.
> We can easily support reading from multiple gcov files instead of one
> (actually, we already support it when llvm is used, since it doesn't support
> the intermediate format).
> The only problem is that it slows down parsing for large projects, which is
> unfortunate since I guess the intermediate format was introduced to speed-up
> parsing. We have a lot of included files (e.g. I just run it with one of our
> gcno files and it generated 160
> gcov files), so clearly opening and reading thousands of files is faster
> than opening and reading hundreds of thousands.

Agree, so let's print it to a single file. I'll work on that.

[Bug other/82784] Remove semicolon after "do {} while (0)" macros

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
So the way it's used is correct ... but why bother with the do {...} while(0)
in that case? It could just use {...} instead.

[Bug gcov-profile/82614] GCOV crashes while parsing gcda file

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
(In reply to Marco Castelluccio from comment #8)
> Created attachment 42462 [details]
> Archive with GCNO and GCDA file generated with GCC 6
> 
> This is an archive containing the GCNO and GCDA files generated with GCC 6.
> 
> We are going to test 7 next.

Thanks for that. Still can't reproduce and it will be highly probably that it's
related to fact that I do not have source files which are annotated.
Can you please attach them?

Moreover, can you please run it in gdb and paste full backtrace?

[Bug other/82784] Remove semicolon after "do {} while (0)" macros

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Some of these makes sense.
gcc/asan.c makes sense:
#define DEF_SANITIZER_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
  do {  \
decl = add_builtin_function ("__builtin_" NAME, TYPE, ENUM, \
 BUILT_IN_NORMAL, NAME, NULL_TREE); \
set_call_expr_flags (decl, ATTRS);  \
set_builtin_decl (ENUM, decl, true);\
  } while (0);

#include "sanitizer.def"

  /* -fsanitize=object-size uses __builtin_object_size, but that might
 not be available for e.g. Fortran at this point.  We use
 DEF_SANITIZER_BUILTIN here only as a convenience macro.  */
  if ((flag_sanitize & SANITIZE_OBJECT_SIZE)
  && !builtin_decl_implicit_p (BUILT_IN_OBJECT_SIZE))
DEF_SANITIZER_BUILTIN (BUILT_IN_OBJECT_SIZE, "object_size",
   BT_FN_SIZE_CONST_PTR_INT,
   ATTR_PURE_NOTHROW_LEAF_LIST)

 CUT -
DEF_SANITIZER_BUILTIN is used inside sanitizer.def without the semi-colon.

[Bug c++/82085] [6 Regression] ICE: Template variable reference used in nested template alias

[paolo.carlini at oracle dot com]

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

--- Comment #13 from Paolo Carlini  ---
Thanks!

[Bug other/82784] New: Remove semicolon after "do {} while (0)" macros

[vries at gcc dot gnu.org]

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

Bug ID: 82784
   Summary: Remove semicolon after "do {} while (0)" macros
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Wrapping a multi-statement macro body in "do {} while (0)" in order to use the
macro as a single-statement entity only works if the macro body is not
terminated with a semicolon.

However, that still seems to happen, f.i.:
...
$ egrep -d skip 'while \((0|false)\);' gcc/*
gcc/asan.c:  } while (0);
gcc/defaults.h:  } while (0);
gcc/graphite-scop-detection.c:} while (0);
gcc/print-rtl-function.c:  } while (0);
gcc/read-rtl-function.c:  } while (0);
gcc/reload.c:  while (0);
...

[Bug hsa/82771] FAIL: brig.dg/test/gimple/packed.hsail (internal compiler error)

[visit0r at gcc dot gnu.org]

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

--- Comment #1 from visit0r at gcc dot gnu.org ---
Author: visit0r
Date: Tue Oct 31 13:00:53 2017
New Revision: 254265

URL: https://gcc.gnu.org/viewcvs?rev=254265=gcc=rev
Log:
[BRIGFE] Fix PR 82771.

Modified:
trunk/gcc/brig/ChangeLog
trunk/gcc/brig/brig-lang.c

[Bug debug/82769] [8 regression] gcc.dg/guality/pr68037-1.c multiple fails

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
Dup.

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

[Bug debug/81570] create_pseudo_cfg assumes that INCOMING_FRAME_SP_OFFSET is a constant

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||andrey.y.guskov at intel dot 
com

--- Comment #5 from H.J. Lu  ---
*** Bug 82769 has been marked as a duplicate of this bug. ***

[Bug c++/82781] [6/7/8 Regression] Vector extension operators return wrong result in constexpr

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

  Known to work||5.4.0
   Target Milestone|--- |6.5
Summary|Vector extension operators  |[6/7/8 Regression] Vector
   |return wrong result in  |extension operators return
   |constexpr   |wrong result in constexpr

--- Comment #1 from Marc Glisse  ---
Have to write static_assert( ... ,"") with earlier compilers, but gcc-6 is the
first that fails.

[Bug c++/81716] Bogus -Wlto warning with forward-declared pointers

[sgunderson at bigfoot dot com]

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

--- Comment #2 from sgunderson at bigfoot dot com ---
Still there in:

gcc version 8.0.0 20171017 (experimental) [trunk revision 253812] (Debian
20171017-1)

[Bug c++/82781] Vector extension operators return wrong result in constexpr

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-31
 Ever confirmed|0   |1

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Matti Bryce from comment #0)
> My .i file is (far) too big to be uploaded directly

Not if you compress it with zip, gzip, bzip2 or something similar.

(In reply to Matti Bryce from comment #7)
> I've attempted to reduce a test case, but after 2 days of running creduce,
> the produced file won't generate the error.

Then you're using creduce wrong. Each step needs to verify it still produces
the same error.

[Bug tree-optimization/82776] Unable to optimize the loop when iteration count is unavailable.

[amker at gcc dot gnu.org]

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

--- Comment #7 from amker at gcc dot gnu.org ---
Testing a patch.

[Bug gcov-profile/82633] Document GCOV and function removal (-fkeep-inline-functions, -fkeep-static-functions)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||6.4.0, 7.2.0

--- Comment #11 from Martin Liška  ---
Fixed on trunk, queued for backporting.

[Bug gcov-profile/82633] Document GCOV and function removal (-fkeep-inline-functions, -fkeep-static-functions)

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
Author: marxin
Date: Tue Oct 31 11:55:19 2017
New Revision: 254257

URL: https://gcc.gnu.org/viewcvs?rev=254257=gcc=rev
Log:
GCOV: document behavior of -fkeep-{static,inline}-functions (PR
gcov-profile/82633).

2017-10-31  Martin Liska  

PR gcov-profile/82633
* doc/gcov.texi: Document -fkeep-{static,inline}-functions and
their interaction with GCOV infrastructure.
* configure.ac: Add -fkeep-{inline,static}-functions to
coverage_flags.
* configure: Regenerate.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/gcc/doc/gcov.texi

[Bug fortran/82783] New: gfotran ICEs when compiling polymorphic function call

[aluaces at udc dot es]

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

Bug ID: 82783
   Summary: gfotran ICEs when compiling polymorphic function call
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aluaces at udc dot es
  Target Milestone: ---

Created attachment 42504
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42504=edit
Minimal test example with Makefile

The attached test example triggers an ICE when it steps into a polymorphic
function call.

[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765

[amker at gcc dot gnu.org]

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

--- Comment #10 from amker at gcc dot gnu.org ---
(In reply to amker from comment #9)
> (In reply to Markus Trippelsdorf from comment #8)
> > I think -fno-strict-overflow/-fwrapv should use the old behavior.
> > The kernel really needs a flag to control pointer wrapping.
> 
> Well, GCC doesn't provide such a flag now.  Before the change, it was
> -fno-strict-overflow/-fwrapv.  And the support for wrapping pointer is far
> from complete, that's one point of the change.

Oh, sorry for mis-understanding,  now I see you prefer to revert the change :)

[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765

[amker at gcc dot gnu.org]

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

--- Comment #9 from amker at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #8)
> I think -fno-strict-overflow/-fwrapv should use the old behavior.
> The kernel really needs a flag to control pointer wrapping.

Well, GCC doesn't provide such a flag now.  Before the change, it was
-fno-strict-overflow/-fwrapv.  And the support for wrapping pointer is far from
complete, that's one point of the change.

[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765

[trippels at gcc dot gnu.org]

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

--- Comment #8 from Markus Trippelsdorf  ---
I think -fno-strict-overflow/-fwrapv should use the old behavior.
The kernel really needs a flag to control pointer wrapping.

[Bug tree-optimization/82776] Unable to optimize the loop when iteration count is unavailable.

[amker at gcc dot gnu.org]

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

--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to amker from comment #4)
> > Well, one decision needs to be made is whether such bound information should
> > be covered by -faggressive-loop-optimizations.  We already did this for
> > undefined behavior of sign type and array bound.  OTOH, this doesn't look
> > like too aggressive since we already rely on undefined behavior for
> > pointer/signed types in SCEV.
> 
> Given:
>   if (flag_aggressive_loop_optimizations)
> infer_loop_bounds_from_undefined (loop);
> I think it should be keyed on flag_aggressive_loop_optimizations.
Base IVs are a bit special and different to existing undefined behavior here. 
IIUC, non-wrap has been assumed all the places in IV/SCEV analysis and that
information has been used in niter analysis without
flag_aggressive_loop_optimizations already.

> E.g. we want to avoid something like that when sanitizing etc.
> 
> > Note I made change assuming non-wrap pointer all the time in r250765, but
> > seems some kernel code depends on that, i.e, PR82694.  We may need to revert
> > the change and only assume non-wrap pointer when !flag_wrapv.  Thanks.
> 
> IMHO the kernel should be fixed, in any case, that is something to discuss
> in that PR, not here.

[Bug tree-optimization/82776] Unable to optimize the loop when iteration count is unavailable.

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to amker from comment #4)
> Well, one decision needs to be made is whether such bound information should
> be covered by -faggressive-loop-optimizations.  We already did this for
> undefined behavior of sign type and array bound.  OTOH, this doesn't look
> like too aggressive since we already rely on undefined behavior for
> pointer/signed types in SCEV.

Given:
  if (flag_aggressive_loop_optimizations)
infer_loop_bounds_from_undefined (loop);
I think it should be keyed on flag_aggressive_loop_optimizations.
E.g. we want to avoid something like that when sanitizing etc.

> Note I made change assuming non-wrap pointer all the time in r250765, but
> seems some kernel code depends on that, i.e, PR82694.  We may need to revert
> the change and only assume non-wrap pointer when !flag_wrapv.  Thanks.

IMHO the kernel should be fixed, in any case, that is something to discuss in
that PR, not here.

[Bug target/82772] GCC crashes as compiling ags_thread.c source file on alpha architecture

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |6.5

--- Comment #9 from Uroš Bizjak  ---
Fixed everywhere.

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
(In reply to Matti Bryce from comment #7)
> (In reply to Martin Liška from comment #5)
> > Confirmed with cross compiler, I reduce a test-case.
> 
> I've attempted to reduce a test case, but after 2 days of running creduce,
> the produced file won't generate the error.

Hi. Looks you hit stack overflow. In that case, please use ulimit and set
smaller stack, that will simplify the reduction. You have to properly write
creduce script that will catch the ICE:
https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction

And please use -fmax-errors=1 which will guarantee that reduced test-case will
be a valid code.

Please either download debug symbols for GCC package. Or build your own from
source: https://gcc.gnu.org/install/configure.html

Feel free to ask for questions..

[Bug tree-optimization/82776] Unable to optimize the loop when iteration count is unavailable.

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Well, one decision needs to be made is whether such bound information should be
covered by -faggressive-loop-optimizations.  We already did this for undefined
behavior of sign type and array bound.  OTOH, this doesn't look like too
aggressive since we already rely on undefined behavior for pointer/signed types
in SCEV.
Note I made change assuming non-wrap pointer all the time in r250765, but seems
some kernel code depends on that, i.e, PR82694.  We may need to revert the
change and only assume non-wrap pointer when !flag_wrapv.  Thanks.

[Bug target/82772] GCC crashes as compiling ags_thread.c source file on alpha architecture

[uros at gcc dot gnu.org]

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

--- Comment #8 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Oct 31 10:36:33 2017
New Revision: 254255

URL: https://gcc.gnu.org/viewcvs?rev=254255=gcc=rev
Log:
PR target/82772
* config/alpha/sync.md (fetchop_constr) : Change to "rINM".


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/alpha/sync.md

[Bug c++/82782] New: ICE: nested template alias and specialized template with auto template parameter

[rbock at eudoxos dot de]

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

Bug ID: 82782
   Summary: ICE: nested template alias and specialized template
with auto template parameter
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rbock at eudoxos dot de
  Target Milestone: ---

Follow up to bug 82085:

This valid code now creates an internal compiler error:

// -
template 
struct make_char_sequence;

template 
struct make_char_sequence
{
  using type = int;
};

template 
using make_char_sequence_t = typename make_char_sequence::type;

inline constexpr char sample[] = "Sample";

using X = make_char_sequence_t;
// -

g++ (GCC) 8.0.0 20171030 (experimental)

test.cpp: In substitution of ‘template using
make_char_sequence_t = typename make_char_sequence::type [with const auto&
StringLiteral = sample]’:
test.cpp:15:38:   required from here
test.cpp:11:78: internal compiler error: unexpected expression ‘N’ of kind
template_parm_index
 using make_char_sequence_t = typename make_char_sequence::type;
  ^
0x6bd33a cxx_eval_constant_expression
../../gcc-trunk/gcc/cp/constexpr.c:4638
0x6c197d cxx_eval_outermost_constant_expr
../../gcc-trunk/gcc/cp/constexpr.c:4697
0x6c4c46 maybe_constant_value(tree_node*, tree_node*)
../../gcc-trunk/gcc/cp/constexpr.c:4912
0x7198b4 compute_array_index_type(tree_node*, tree_node*, int)
../../gcc-trunk/gcc/cp/decl.c:9349
0x833768 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-trunk/gcc/cp/pt.c:13680
0x833538 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-trunk/gcc/cp/pt.c:14137
0x83312b tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-trunk/gcc/cp/pt.c:13626
0x82e7f5 unify
../../gcc-trunk/gcc/cp/pt.c:20908
0x82f40f unify
../../gcc-trunk/gcc/cp/pt.c:21328
0x82f1e7 unify
../../gcc-trunk/gcc/cp/pt.c:21100
0x830232 get_partial_spec_bindings
../../gcc-trunk/gcc/cp/pt.c:21906
0x830ab1 most_specialized_partial_spec
../../gcc-trunk/gcc/cp/pt.c:22178
0x858107 instantiate_class_template_1
../../gcc-trunk/gcc/cp/pt.c:10341
0x858107 instantiate_class_template(tree_node*)
../../gcc-trunk/gcc/cp/pt.c:10909
0x8b12a2 complete_type(tree_node*)
../../gcc-trunk/gcc/cp/typeck.c:136
0x83403f tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-trunk/gcc/cp/pt.c:14208
0x83dec6 tsubst_decl
../../gcc-trunk/gcc/cp/pt.c:13043
0x833e17 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-trunk/gcc/cp/pt.c:13553
0x83130d instantiate_template_1
../../gcc-trunk/gcc/cp/pt.c:18502
0x83130d instantiate_template(tree_node*, tree_node*, int)
../../gcc-trunk/gcc/cp/pt.c:18558


Minimized example, based on this code:
you can observe the code here:
https://github.com/rbock/sqlpp17/tree/1c424f9c1e4d9d9fa7e1c0cb48d27aec190f0da7

Compile with something something like:
export SOURCE_ROOT=$HOME/projects/sqlpp17
/usr/local/gcc-trunk/bin/g++-I$SOURCE_ROOT/include -I$SOURCE_ROOT/tests 
-std=c++1z -Wall -Wpedantic $SOURCE_ROOT/tests/serialize/join.cpp

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Created attachment 42503
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42503=edit
Slightly reduced test-case

With following test-case, I see ICE with following cross-compiler:
../configure --enable-languages=c,c++ --disable-multilib --disable-libsanitizer
--prefix=/home/marxin/bin/gcc --disable-bootstrap --target=x86_64-w64-mingw32
--enable-checking=no

$ ./xg++ -B. ice.ii -std=c++1z -mavx512dq -c -O2 -g  --param ggc-min-heapsize=0
In file included from C:/msys64/mingw64/include/c++/7.2.0/locale:42:0,
 from C:/msys64/mingw64/include/c++/7.2.0/iomanip:37,
 from C:/repos/gassim/src/Control/Manager.cpp:7:
C:/msys64/mingw64/include/c++/7.2.0/bits/locale_conv.h:140:5: internal compiler
error: Segmentation fault
0xaffb9f crash_signal
../../gcc/toplev.c:326
0x77aeb6 lookup_page_table_entry
../../gcc/ggc-page.c:646
0x77aeb6 ggc_set_mark(void const*)
../../gcc/ggc-page.c:1536
0x6fc0f1 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:136
0x6fdc07 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:526
0x6351b1 ggc_remove::ggc_mx(tree_node*&)
../../gcc/hash-traits.h:235
0x6351b1 gt_ggc_mx
../../gcc/hash-table.h:1047
0x6351b1 gt_ggc_mx_hash_table_mangled_decl_hash_(void*)
./gt-cp-decl2.h:28
0x8e0ba5 ggc_mark_root_tab
../../gcc/ggc-common.c:77
0x8e0e80 ggc_mark_roots()
../../gcc/ggc-common.c:94
0x77b7c5 ggc_collect()
../../gcc/ggc-page.c:2206
0x6e9304 expand_or_defer_fn_1(tree_node*)
../../gcc/cp/semantics.c:4177
0x6e9378 expand_or_defer_fn(tree_node*)
../../gcc/cp/semantics.c:4236
0x6a2a14 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:26756
0x6a3635 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:26667
0x6a3635 cp_parser_init_declarator
../../gcc/cp/parser.c:19526
0x6a83ea cp_parser_single_declaration
../../gcc/cp/parser.c:27207
0x6a85ac cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.c:26809
0x6a8b95 cp_parser_explicit_template_declaration
../../gcc/cp/parser.c:27046
0x6a8b95 cp_parser_template_declaration_after_export
../../gcc/cp/parser.c:27065

[Bug c++/82085] [6 Regression] ICE: Template variable reference used in nested template alias

[rbock at eudoxos dot de]

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

--- Comment #12 from Roland B  ---
Done, reported as bug 82782. Thanks for your help!

[Bug target/82772] GCC crashes as compiling ags_thread.c source file on alpha architecture

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Oct 31 10:34:55 2017
New Revision: 254254

URL: https://gcc.gnu.org/viewcvs?rev=254254=gcc=rev
Log:
PR target/82772
* config/alpha/sync.md (fetchop_constr) : Change to "rINM".


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/alpha/sync.md

[Bug target/82772] GCC crashes as compiling ags_thread.c source file on alpha architecture

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Oct 31 10:33:12 2017
New Revision: 254253

URL: https://gcc.gnu.org/viewcvs?rev=254253=gcc=rev
Log:
PR target/82772
* config/alpha/sync.md (fetchop_constr) : Change to "rINM".


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/alpha/sync.md

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #5 from Tamar Christina  ---
My patch adds support for 


```
#pragma GCC push_options
#pragma GCC target("arch=armv8-a+crc")
__attribute__((target("arch=armv8-a+crc"))) uint32_t crc32cw(uint32_t crc,
uint32_t val)
```

and just


```
#pragma GCC push_options
#pragma GCC target("+crc")
__attribute__((target("+crc"))) uint32_t crc32cw(uint32_t crc, uint32_t val)
```

if the compiler was invoked with `-march=armv8-a`.

However it currently doesn't allow


```
#pragma GCC push_options
#pragma GCC target("armv8-a+crc")
__attribute__((target("armv8-a+crc"))) uint32_t crc32cw(uint32_t crc, uint32_t
val)
```

as it doesn't know if you wanted to change the `fpu` or `arch` here.
Should I support this case as well?

[Bug tree-optimization/82776] Unable to optimize the loop when iteration count is unavailable.

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #3 from amker at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
> Perhaps at least when seeing an unconditional POINTER_PLUS_EXPR with
> constant increment and no other bumps for the same pointer in the loop, we
> could derive upper niter bound from that, even when the loop has multiple
> exits etc.

Yes.  GCC's niter analyzer only analyzes exit condition with induction variable
involved while it's not the case here.  As a result, niter analysis is skipped
for the loop.  In this code, the no-wrapping information is actually with the
IV, as you suggested, we should be able to refine bound information when niter
analysis of exit condition is skipped.   I will have a look.  Thanks.

[Bug c/78829] bit-rotten "C99 mode" references in GCC manual

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
https://gcc.gnu.org/onlinedocs/gcc/Alignment.html should discuss the
relationship between GCC's __alignof__ and C11's _Alignof. Are they identical?
Should _Alignof be preferred when using C11? It could also mention _Alignas,
and the macros (keywords in C++11 and later) alignof and alignas.

[Bug target/82772] GCC crashes as compiling ags_thread.c source file on alpha architecture

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Joël Krähemann from comment #4)
> Hi,
> Yesterday I was trying to set up an alpha VM. Since I didn't build it I
> don't have access to the preprocessed source.
> 
> As doing a qemu image with debian there were some problems with the kernel.
> The pool contained a different version than the installer was using.
> 
> But I try to limit the problem as soon I have a running VM.

Well, the fix is kind of "obvious". I'll just commit the fix to mainline and
release branches and close the PR. Please reopen it, if the compilation still
fails afterwards.

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-31
 CC||ramana at gcc dot gnu.org,
   ||tnfchris at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Ramana Radhakrishnan  ---
(In reply to Yichao Yu from comment #3)
> > ARMv8-a is the only architecture variant where the CRC extension is optional
> 
> Not really. There's also armv8-r and armv8-m. Also, I believe code compiled

armv8-m does not have the CRC extension though armv8-r does have CRC as
optional IIRC.

Tamar isn't this something you've been looking at recently ?

Anyway confirmed with the testcase.

[Bug target/82674] ICE with -fstack-clash-protection

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
Author: segher
Date: Tue Oct 31 09:49:40 2017
New Revision: 254252

URL: https://gcc.gnu.org/viewcvs?rev=254252=gcc=rev
Log:
Subject: [PATCH] rs6000: Fix crash with big stack clash interval (PR82674)

If the user asks for a stack clash probe interval of 64kB, we currently
generate a "stdu rX,-65536(r1)" instruction.  That instruction does not
exist (the offset is a 16-bit signed number).  If the offset is too big
we should force it into a register and generate a "stdux rX,rY,r1"
instruction, instead.


PR target/82674
* config/rs6000/rs6000.md (allocate_stack): Force update interval
into a register if it does not fit into an immediate offset field.

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

[Bug c++/82781] New: Vector extension operators return wrong result in constexpr

[florent.hivert at lri dot fr]

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

Bug ID: 82781
   Summary: Vector extension operators return wrong result in
constexpr
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: florent.hivert at lri dot fr
  Target Milestone: ---

The following code shows the expected behavior of the == operator on vector:

#include

using foo = int __attribute__ ((vector_size (16)));

int main() {
  const foo b1 = {0, 1, 10, 20};
  const foo b2 = {0, 2, 10, 0};
  const foo b3 = b1 == b2;

  assert (b3[0] == 0x);
  assert (b3[1] == 0x0);
  assert (b3[2] == 0x);
  assert (b3[3] == 0x0);
}

However replacing const by constexpr breaks everything:

using foo = int __attribute__ ((vector_size (16)));

constexpr foo b1 = {0, 1, 10, 20};
constexpr foo b2 = {0, 2, 10, 0};
constexpr foo b3 = b1 == b2;

static_assert (b3[0] == 0x);
static_assert (b3[1] == 0x0);
static_assert (b3[2] == 0x);
static_assert (b3[3] == 0x0);

When compiled with

g++-7 -std=c++14 bug-const.cpp

gives

bug-const.cpp:8:1: error: l'assertion statique a échoué
 static_assert (b3[1] == 0x0);
 ^
bug-const.cpp:10:1: error: l'assertion statique a échoué
 static_assert (b3[3] == 0x0);
 ^

where is should pass.

Best,

Florent

[Bug c++/82780] [8 Regression] ICE on compiling Boost

[sgunderson at bigfoot dot com]

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

--- Comment #1 from sgunderson at bigfoot dot com ---
Here's a version that's valid C++:

class a {
};
template  class c {  c(c &)   : a(static_cast
(e.d)) {}  a d; };

[Bug c++/82360] [8 Regression] tree check fail in get_inner_reference, at expr.c:6996

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||sgunderson at bigfoot dot com

--- Comment #7 from Markus Trippelsdorf  ---
*** Bug 82780 has been marked as a duplicate of this bug. ***

[Bug c++/82780] [8 Regression] ICE on compiling Boost

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Markus Trippelsdorf  ---
dup.

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

[Bug c++/82780] New: [8 Regression] ICE on compiling Boost

[sgunderson at bigfoot dot com]

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

Bug ID: 82780
   Summary: [8 Regression] ICE on compiling Boost
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sgunderson at bigfoot dot com
  Target Milestone: ---

Hi,

Reduced test case below. Regression happens when compiling a part of MySQL
which uses Boost (1.65.0); original code was valid but reduced case is not.
(Reduction also independently found #82050.) GCC 7 does not complain.

gcc version 8.0.0 20171017 (experimental) [trunk revision 253812] (Debian
20171017-1) 

atum17:~> cat ~/reduce2/tmp.i   
class a {  
} template  class c {  c(c &)   : (static_cast a && e.d;  
   a d

atum17:~> /usr/lib/gcc-snapshot/bin/g++  -c ~/reduce2/tmp.i 
[...]
/srv/sesse/reduce2/tmp.i:2:72: internal compiler error: tree check: expected
tree that contains 'decl common' structure, have 'identifier_node' in
get_inner_reference, at expr.c:6999
 } template  class c {  c(c &)   : (static_cast a && e.d; 
a d
^

[Bug c++/82085] [6 Regression] ICE: Template variable reference used in nested template alias

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  ---
Just to clarify why I think a separate bug report is more appropriate: if I
revert the small change I committed for this bug, the new testcase does *not*
trigger the ICE fixed here.

[Bug c++/82085] [6 Regression] ICE: Template variable reference used in nested template alias

[paolo.carlini at oracle dot com]

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

--- Comment #10 from Paolo Carlini  ---
Yes, please, open a new bug, it's a different issue.

[Bug fortran/82567] [6/7/8] gfortran takes a long time to compile a simple implied-do with -Optimization.

[chinoune.mehdi at hotmail dot com]

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

--- Comment #7 from Chinoune  ---
Fixed

[Bug target/82772] GCC crashes as compiling ags_thread.c source file on alpha architecture

[jkraehemann at gmail dot com]

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

--- Comment #4 from Joël Krähemann  ---
Hi,
Yesterday I was trying to set up an alpha VM. Since I didn't build it I don't
have access to the preprocessed source.

As doing a qemu image with debian there were some problems with the kernel. The
pool contained a different version than the installer was using.

But I try to limit the problem as soon I have a running VM.

[Bug fortran/82567] [6/7/8] gfortran takes a long time to compile a simple implied-do with -Optimization.

[chinoune.mehdi at hotmail dot com]

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

Chinoune  changed:

   What|Removed |Added

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

--- Comment #6 from Chinoune  ---
Fixed

[Bug bootstrap/82670] UBSAN bootstrap broken after recent libsanitizer merge

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #2 from Markus Trippelsdorf  ---
*** Bug 82779 has been marked as a duplicate of this bug. ***

[Bug sanitizer/82779] [8 regression] On ppc64le bootstrap-ubsan causes "gcc -dumpspecs" segfault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Sorry, dup.

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

[Bug rtl-optimization/82778] crash: insn does not satisfy its constraints

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||collison at gcc dot gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Dup of PR 82597?
Michael has posted a patch at
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01317.html waiting for review.

On the reversion: Unfortunately, I don't have any time to work on improving the
approach in that patch to address the compile-time implications.
Michael, if you don't plan to work on that either, can you please revert it?
If we end up reverting it, I guess we won't need to apply any fix for these
ICEs.

[Bug c++/82085] [6 Regression] ICE: Template variable reference used in nested template alias

[rbock at eudoxos dot de]

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

--- Comment #9 from Roland B  ---
Here is the new minimal example (please let me know if this should go into a
new bug report):

// -
template 
struct make_char_sequence;

template 
struct make_char_sequence
{
  using type = int;
};

template 
using make_char_sequence_t = typename make_char_sequence::type;

inline constexpr char sample[] = "Sample";

using X = make_char_sequence_t;
// -

g++ (GCC) 8.0.0 20171030 (experimental)

test.cpp: In substitution of ‘template using
make_char_sequence_t = typename make_char_sequence::type [with const auto&
StringLiteral = sample]’:
test.cpp:15:38:   required from here
test.cpp:11:78: internal compiler error: unexpected expression ‘N’ of kind
template_parm_index
 using make_char_sequence_t = typename make_char_sequence::type;
  ^
0x6bd33a cxx_eval_constant_expression
../../gcc-trunk/gcc/cp/constexpr.c:4638
0x6c197d cxx_eval_outermost_constant_expr
../../gcc-trunk/gcc/cp/constexpr.c:4697
0x6c4c46 maybe_constant_value(tree_node*, tree_node*)
../../gcc-trunk/gcc/cp/constexpr.c:4912
0x7198b4 compute_array_index_type(tree_node*, tree_node*, int)
../../gcc-trunk/gcc/cp/decl.c:9349
0x833768 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-trunk/gcc/cp/pt.c:13680
0x833538 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-trunk/gcc/cp/pt.c:14137
0x83312b tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-trunk/gcc/cp/pt.c:13626
0x82e7f5 unify
../../gcc-trunk/gcc/cp/pt.c:20908
0x82f40f unify
../../gcc-trunk/gcc/cp/pt.c:21328
0x82f1e7 unify
../../gcc-trunk/gcc/cp/pt.c:21100
0x830232 get_partial_spec_bindings
../../gcc-trunk/gcc/cp/pt.c:21906
0x830ab1 most_specialized_partial_spec
../../gcc-trunk/gcc/cp/pt.c:22178
0x858107 instantiate_class_template_1
../../gcc-trunk/gcc/cp/pt.c:10341
0x858107 instantiate_class_template(tree_node*)
../../gcc-trunk/gcc/cp/pt.c:10909
0x8b12a2 complete_type(tree_node*)
../../gcc-trunk/gcc/cp/typeck.c:136
0x83403f tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-trunk/gcc/cp/pt.c:14208
0x83dec6 tsubst_decl
../../gcc-trunk/gcc/cp/pt.c:13043
0x833e17 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-trunk/gcc/cp/pt.c:13553
0x83130d instantiate_template_1
../../gcc-trunk/gcc/cp/pt.c:18502
0x83130d instantiate_template(tree_node*, tree_node*, int)
../../gcc-trunk/gcc/cp/pt.c:18558

[Bug sanitizer/82779] New: [8 regression] On ppc64le bootstrap-ubsan causes "gcc -dumpspecs" segfault

[trippels at gcc dot gnu.org]

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

Bug ID: 82779
   Summary: [8 regression] On ppc64le bootstrap-ubsan causes "gcc
-dumpspecs" segfault
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

On ppc64le --with-build-config=bootstrap-ubsan:

trippels@gcc2-power8 gcc_build_dir_ % gdb --args
/home/trippels/gcc_build_dir_/./gcc/xgcc -B/home/trippels/gcc_build_dir_/./gcc/
-dumpspecs
Reading symbols from /home/trippels/gcc_build_dir_/./gcc/xgcc...done.
(gdb) run
Starting program: /home/trippels/gcc_build_dir_/gcc/xgcc
-B/home/trippels/gcc_build_dir_/./gcc/ -dumpspecs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x1028cb44 in __interceptor_signal (signum=,
handler=0x1) at
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_signal_interceptors.inc:32
#2  0x10020130 in driver::global_initializations (this=0x3fffec30)
at ../../gcc/gcc/gcc.c:7391
#3  0x10003f84 in driver::main (this=0x3fffec30, argc=, argv=) at ../../gcc/gcc/gcc.c:7302
#4  0x100045a8 in main (argc=, argv=0x3068) at
../../gcc/gcc/gcc-main.c:46

[Bug rtl-optimization/82778] crash: insn does not satisfy its constraints

[jakub at gcc dot gnu.org]

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

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

The following untested patch ought to fix it.
recog_memoized doesn't handle the important part insn_invalid_p does:
/* After reload, verify that all constraints are satisfied.  */
so it happily created an instruction that is wrong after reload.

I still wonder if the patch shouldn't be reverted or at least if the changes
can't be limited to targets that would benefit from that (perhaps target hook
to signal it needs it)?

[Bug c++/82085] [6 Regression] ICE: Template variable reference used in nested template alias

[rbock at eudoxos dot de]

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

--- Comment #8 from Roland B  ---
(In reply to Paolo Carlini from comment #7)
> Fixed trunk and 7.3.0 so far.

Awesome!

Sadly, my "real" code still produces an internal compile error. I will try to
create a new minimal example.

Until then, you can observe the code here:
https://github.com/rbock/sqlpp17/tree/1c424f9c1e4d9d9fa7e1c0cb48d27aec190f0da7

And then something like:
export SOURCE_ROOT=$HOME/projects/sqlpp17
/usr/local/gcc-trunk/bin/g++-I$SOURCE_ROOT/include -I$SOURCE_ROOT/tests 
-std=c++1z -Wall -Wpedantic $SOURCE_ROOT/tests/serialize/join.cpp

This creates:
sqlpp17/char_sequence.h:70:80: internal compiler error: unexpected expression
‘N’ of kind template_parm_index
   using make_char_sequence_t = typename
make_char_sequence::type;
   
^
0x6bd33a cxx_eval_constant_expression
../../gcc-trunk/gcc/cp/constexpr.c:4638
...

[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
*** Bug 82485 has been marked as a duplicate of this bug. ***

[Bug target/82485] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13232

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|tree-optimization   |target
 Resolution|--- |DUPLICATE

--- Comment #5 from Uroš Bizjak  ---
Dup.

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

[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
*** Bug 82712 has been marked as a duplicate of this bug. ***

[Bug target/82712] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:11383

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #2 from Uroš Bizjak  ---
Dup.

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

[Bug rtl-optimization/82778] crash: insn does not satisfy its constraints

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Started with r253764.  I believe that patch should have been reverted at least
due to the compile time regressions.

[Bug tree-optimization/82776] Unable to optimize the loop when iteration count is unavailable.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Perhaps at least when seeing an unconditional POINTER_PLUS_EXPR with constant
increment and no other bumps for the same pointer in the loop, we could derive
upper niter bound from that, even when the loop has multiple exits etc.

[Bug tree-optimization/82776] Unable to optimize the loop when iteration count is unavailable.

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
That could be because gcc sadly refuses to optimize away infinite loops
(happens for other cases, and cddce2 dump (the pass that removes the whole
thing when the macro is defined) says "can not prove finiteness of loop 2").
Although ++chunk_ should be enough to prove that the loop terminates (otherwise
chunk_ eventually overflows).

(the unaligned vector use in this code seems strange)