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

[asolokha at gmx dot com]

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

Bug ID: 88213
   Summary: ICE in change_address_1, at emit-rtl.c:2286
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu

gcc-9.0.0-alpha20181125 snapshot (r266441) ICEs when compiling
gcc/testsuite/gcc.target/powerpc/sse-movlps-1.c at any optimization level w/
-mcpu=power7 (=power8) -ffloat-store:

% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181125 -mcpu=power7 -O1
-ffloat-store -c gcc/testsuite/gcc.target/powerpc/sse-movlps-1.c
during RTL pass: split2
gcc/testsuite/gcc.target/powerpc/sse-movlps-1.c: In function 'test':
gcc/testsuite/gcc.target/powerpc/sse-movlps-1.c:25:1: internal compiler error:
in change_address_1, at emit-rtl.c:2286
   25 | }
  | ^
0x5c5883 change_address_1
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/emit-rtl.c:2286
0x99bc59 change_address(rtx_def*, machine_mode, rtx_def*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/emit-rtl.c:2311
0x12f7cdc gen_split_551(rtx_insn*, rtx_def**)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/config/rs6000/vsx.md:3253
0x9a1280 try_split(rtx_def*, rtx_insn*, int)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/emit-rtl.c:3851
0xc78b18 split_insn
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/recog.c:2893
0xc7dc9c split_all_insns()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/recog.c:2997
0xc7ddb8 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/recog.c:3897

[Bug rtl-optimization/88212] IRA Register Coalescing not working for the testcase

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization, ra

--- Comment #1 from Andrew Pinski  ---
Subreg's have been always a hard problem to solve.

[Bug rtl-optimization/88212] New: IRA Register Coalescing not working for the testcase

[kugan at gcc dot gnu.org]

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

Bug ID: 88212
   Summary: IRA Register Coalescing not working for the testcase
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kugan at gcc dot gnu.org
  Target Milestone: ---

When compiling the following on aarch64 with -O2:
#include 
void g(int32_t *p, int32x2x2_t val, int x)
{
 vst2_lane_s32(p,val,0);
}

generates:
.cfi_startproc
mov v2.8b, v0.8b
mov v3.8b, v1.8b
st2 {v2.s - v3.s}[0], [x0]
ret

clang produces:
st2 { v0.s, v1.s }[0], [x0]
ret

Essentially the problem is that access to part-registers doesn't get
coalesced, so IRA generates moves which aren't actually required.

[Bug fortran/88190] compile_options.allow_std does not allow to distinguish between GFC_STD_GNU and GFC_STD_LEGACY

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #0)
> While playing with pr88052 I have found that the value of
> compile_options.allow_std passed to libgfortran is the same (4095) when
> compiling with -std=gnu or -std=legacy.
> 

I have been giving this some thought. After reading our current documentation
for -std= why do we all of a sudden change a policy because the reporter of
88052 does not like something? Why not just keep the current behavior and use
the allow_std for pr88052 and allow the extension with -std=gnu and default.
Then when user wants more rigorous compliance then use -std=f95, etc. as is
done now.

This way we dont mess around with all existing behaviors that people are use
to.

Then for the few cases where we want it we can define a new macro as:

#define GFC_LEGACY_ONLY (compile_options.warn_std == 0) and use that in the
unique case of pr78351.

Just some thoughts to avoid major ripple.

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[gcc at kalvdans dot no-ip.org]

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

--- Comment #31 from Christian Häggström  ---
What you describe Sandra is mentioned in the man page for longjmp(3). Maybe we
can steal some of its documentation.

   Caveats
   If  the  function  which  called  setjmp()  returns before longjmp() is
   called, the behavior is undefined.  Some kind  of  subtle  or  unsubtle
   chaos is sure to result.

[Bug c++/88210] Add fix-it hint for explicit template instantiations

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-27
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from David Malcolm  ---
Confirmed; working on a fix.

[Bug testsuite/88208] new test case c-c++-common/builtin-has-attribute-3.c in r266335 has multiple excess errors

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Confirmed.  The failures are being discussed in the following thread:
  https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01913.html
I expect to submit a patch soon.

[Bug middle-end/88211] missing warning on printf %ls and unterminated wide member array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
See also bug 87756.

[Bug tree-optimization/87756] missing unterminated argument warning using address of a constant character

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Mon Nov 26 23:55:36 2018
New Revision: 266494

URL: https://gcc.gnu.org/viewcvs?rev=266494&root=gcc&view=rev
Log:
PR 87756 - missing unterminated argument warning using address of a constant
character

gcc/ChangeLog:

PR 87756
* expr.c (string_constant): Handle top-level decls of all character
types and subobjects of narrow character type.

gcc/testsuite/ChangeLog:

PR 87756
* gcc.dg/warn-sprintf-no-nul-2.c: Move incomplete tests from here...
* gcc.dg/warn-sprintf-no-nul-3.c: ...to here and complete them.


Added:
trunk/gcc/testsuite/gcc.dg/warn-sprintf-no-nul-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/warn-sprintf-no-nul-2.c

[Bug middle-end/88211] New: missing warning on printf %ls and unterminated wide member array

[msebor at gcc dot gnu.org]

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

Bug ID: 88211
   Summary: missing warning on printf %ls and unterminated wide
member array
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC correctly diagnoses the past-the-end read from the narrow character array
in f() but fails to diagnose the equivalent past-the-end read from the wide
character array in g().

$ cat t.c && gcc -O2 -S -Wall t.c
const char a[] = { 'a' };
int f (void)
{
  return __builtin_snprintf (0, 0, "%s", a);   // warning (good)
}

const __WCHAR_TYPE__ wa[] = { L'A' };
int g (void)
{
  return __builtin_snprintf (0, 0, "%ls", wa);   // missing warning
}

t.c: In function ‘f’:
t.c:4:37: warning: ‘%s’ directive argument is not a nul-terminated string
[-Wformat-truncation=]
4 |   return __builtin_snprintf (0, 0, "%s", a);   // warning (good)
  | ^~   ~
t.c:1:12: note: referenced argument declared here
1 | const char a[] = { 'a' };
  |^

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #30 from sandra at gcc dot gnu.org ---
I've been looking at this issue.  The proposed patch has a number of problems,
notably that it uses "@code{setjmp} buffer" to describe the argument that is
*not* the same as the buffer you would pass to the setjmp function.  (It's a
different flavor of buffer.)

I'm also thinking that "@code{__builtin_setjmp} and @code{__builtin_longjmp}
may not be used in the same function with the same @code{setjmp} buffer"
doesn't accurately capture the restriction.  If builtin_setjmp uses its
containing function's prologue/epilogue to do the register saves and restores
(comment 25), it seems like that also implies that builtin_longjmp can only be
called from functions called directly or indirectly from that containing
function.  And indeed, at least on nios2-elf this program wanders off into the
weeds:

#include 

int
my_setjmp (intptr_t *buf)
{
  return __builtin_setjmp (buf);
}

void
my_longjmp (intptr_t *buf)
{
  __builtin_longjmp (buf, 1);
}

int
main (void)
{
  intptr_t buf[5];
  int ret;

  ret = my_setjmp (buf);
  if (ret == 0)
my_longjmp (buf);
  return ret;
}

whereas calling __builtin_setjmp directly from main works and returns 1 as
expected.

[Bug c++/88120] [7/8 Regression] ICE in contains_placeholder_p at gcc/tree.c:3710

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] ICE in   |[7/8 Regression] ICE in
   |contains_placeholder_p at   |contains_placeholder_p at
   |gcc/tree.c:3710 |gcc/tree.c:3710

--- Comment #4 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/88120] [7/8/9 Regression] ICE in contains_placeholder_p at gcc/tree.c:3710

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Mon Nov 26 23:26:40 2018
New Revision: 266492

URL: https://gcc.gnu.org/viewcvs?rev=266492&root=gcc&view=rev
Log:
PR c++/88120 - ICE when calling save_expr in a template.
* typeck.c (cp_build_binary_op): Call cp_save_expr instead of
save_expr.

* g++.dg/cpp0x/pr88120.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr88120.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ebotcazou at gcc dot gnu.org]

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

--- Comment #14 from Eric Botcazou  ---
> The only asan execution failures I see on Solaris 11/SPARC are
> 
> c-c++-common/asan/pointer-compare-1.c   
> c-c++-common/asan/pointer-compare-2.c   
> c-c++-common/asan/pointer-subtract-1.c   
> c-c++-common/asan/pointer-subtract-2.c   
> c-c++-common/asan/pointer-subtract-3.c   
> g++.dg/asan/default-options-1.C   
> g++.dg/asan/function-argument-3.C   
> g++.dg/asan/pr78651.C   
> g++.dg/asan/pr81021.C   

I only have:

c-c++-common/asan/pointer-compare-1.c
c-c++-common/asan/pointer-compare-2.c
c-c++-common/asan/pointer-subtract-1.c
c-c++-common/asan/pointer-subtract-2.c
g++.dg/asan/function-argument-3.C

as execution test failures, but I have a bunch of output pattern test failures.

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  ---
> This is weird: this test PASSes for me on Solaris 11.3, 11.4 and 11.5,
> both 32 and 64-bit, as and gas.

A more useful backtrace just before the crash:

(gdb) bt
#0  0xfe8d9080 in free ()
   from /home/botcazou/gcc-head/install_sparc/lib/libasan.so.5
#1  0xff14de1c in __deregister_frame_info_bases (begin=)
at /homes/botcazou/gcc-head/src/libgcc/unwind-dw2-fde.c:228
#2  __deregister_frame_info_bases (begin=0xff15f044)
at /homes/botcazou/gcc-head/src/libgcc/unwind-dw2-fde.c:201
#3  0xff1435fc in __do_global_dtors_aux ()
   from /home/botcazou/gcc-head/install_sparc/lib/libgcc_s.so.1
#4  0xff14ed80 in _fini ()
   from /home/botcazou/gcc-head/install_sparc/lib/libgcc_s.so.1
#5  0xff1b236c in call_fini () from /usr/lib/ld.so.1
#6  0xff1b24a4 in atexit_fini () from /usr/lib/ld.so.1
#7  0xff05c128 in _exithandle () from /lib/libc.so.1
#8  0xff049f94 in exit () from /lib/libc.so.1
#9  0x00010dfc in _start ()

so libgcc is dereferencing its EH frames by invoking libasan's free...

The bottom line is that you need to HAVE_LD_EH_FRAME_HDR enabled in the
compiler otherwise the sanitizer is unusable (it wasn't because the configure
script requires GNU sed and only found the system sed on the machine).

[Bug driver/78206] bootstrap failure under Apple sandbox that blacklists reads in /usr/local

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mrs at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #8 from mrs at gcc dot gnu.org  ---
Not sure why I didn't already mark this as fixed.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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

--- Comment #20 from Gary Mills  ---
For a test, I defined the symbol DEBUG_ET in gcc-7.3.0/gcc/et-forest.c . 
During
the build, I got this ICE and a backtrace:

/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/xgcc
-B/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/
-nostdinc -x c /dev/null -S -o /dev/null
-fself-test=/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/testsuite/selftests
cc1: internal compiler error: Bus Error

The bus error occurs here, in gcc-7.3.0/gcc/et-forest.c:218:

203 static int
204 record_path_before_1 (struct et_occ *occ, int depth)
205 {
206   int mn, m;
207  
208   depth += occ->depth;
209   mn = depth;
210  
211   if (occ->prev)
212 {
213   m = record_path_before_1 (occ->prev, depth);
214   if (m < mn)
215 mn = m;
216 }
217  
---
218   fprintf (stderr, "%d (%d); ", ((basic_block) occ->of->data)->index,
depth);
---
219  

It's likely dereferencing a NULL pointer.

When I later tested xgcc with my trivial source file, I got this output:

$ build/sparcv7/gcc/xgcc -B build/sparcv7/./gcc/ -S
/tmp/conftest.c
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
4 (0); 
0 (0); 2 (1); 4 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 2 (1); 0 (0); 
3 (0); 
0 (0); 2 (1); 3 (2); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 
0 (0); 
2 (0); 
0 (0); 2 (1); 0 (0); 

The compile was successful.  The output file, conftest.s, had the correct
assembly language.  The debugging output from the compile showed each chain of
blocks within the tree structure.  The first number is the index.  The second,
in brackets, is the depth.  There seems to be some unwanted chains in that
list.
These are always one block long and begin with a non-zero index.  I don't know
the origin of these chains, but they likely cause the ICE when compiling a
regular file.  How do I determine their origin?

[Bug target/52795] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE on {x86_64,i386}-apple-darwin{10,11} at -m64

[mikestump at comcast dot net]

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

--- Comment #15 from Mike Stump  ---
Can the bug be marked as resolved?  :-)

[Bug libstdc++/71044] Optimize std::filesystem implementation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug libstdc++/86756] Don't define __cpp_lib_filesystem unless --enable-libstdcxx-filesystem-ts

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug target/88207] [9 regression] gcc.target/i386/pr22076.c etc. FAIL

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
  Thank you for reporting it.  I've started to work on the PR.  I'll keep you
informed about the progress.

[Bug target/88195] misleading error message for unsupported builtin

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 26 21:26:19 2018
New Revision: 266487

URL: https://gcc.gnu.org/viewcvs?rev=266487&root=gcc&view=rev
Log:
PR target/88195
* config/i386/i386.c (def_builtin2): If tcode == VOID_FTYPE_UINT64
and !TARGET_64BIT, return NULL_TREE.

* gcc.target/i386/pr88195.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr88195.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/88090] [9 regression] obj-c++.dg/attributes/method-nonnull-1.mm FAILs

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 26 21:25:22 2018
New Revision: 266486

URL: https://gcc.gnu.org/viewcvs?rev=266486&root=gcc&view=rev
Log:
PR testsuite/88090
* obj-c++.dg/attributes/method-nonnull-1.mm (my_size_t): New typedef.
(MyArray::removeObjectAtIndex): Use my_size_t instead of size_t and
expect it in diagnostics.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/obj-c++.dg/attributes/method-nonnull-1.mm

[Bug c++/86900] [8/9 Regression] -gdwarf-5 -O2 -ffunction-sections = assembler error

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 26 21:24:00 2018
New Revision: 266485

URL: https://gcc.gnu.org/viewcvs?rev=266485&root=gcc&view=rev
Log:
PR c++/86900
* dwarf2out.c (secname_for_decl): For functions with
DECL_SECTION_NAME if in_cold_section_p, try to return
current_function_section's name if it is a named section.

* g++.dg/debug/dwarf2/pr86900.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr86900.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/58397] Please add host_hooks for NetBSD to make precompiled headers work

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

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

[Bug preprocessor/58370] pre compiled headers failure on NetBSD/sparc64

[law at redhat dot com]

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

Bug 58397 Summary: Please add host_hooks for NetBSD to make precompiled headers 
work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58397

   What|Removed |Added

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

[Bug preprocessor/58397] Please add host_hooks for NetBSD to make precompiled headers work

[law at gcc dot gnu.org]

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

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Mon Nov 26 21:21:16 2018
New Revision: 266484

URL: https://gcc.gnu.org/viewcvs?rev=266484&root=gcc&view=rev
Log:
PR target/58397
* config.host (*-*-netbsd*): Use x-netbsd and host-netbsd.o.
* config/x-netbsd: New file.
* config/host-netbsd: New file.

Added:
trunk/gcc/config/host-netbsd.c
trunk/gcc/config/x-netbsd
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.host

[Bug c++/88210] Add fix-it hint for explicit template instantiations

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Even without a fix-it, "has not been declared" would be more helpful than "is
not a template".

Clang is more informative (although wrong about the instantiation needing to
occur in namespace x):


expl.cc:5:23: error: no template named 'blah'; did you mean 'x::blah'?
extern template class blah;
  ^~~~
  x::blah
expl.cc:2:31: note: 'x::blah' declared here
  template struct blah { };
  ^
expl.cc:5:23: error: explicit instantiation of 'x::blah' must occur in
namespace 'x'
extern template class blah;
  ^
expl.cc:2:31: note: explicit instantiation refers here
  template struct blah { };
  ^
expl.cc:7:16: error: no template named 'blah'; did you mean 'x::blah'?
template class blah;
   ^~~~
   x::blah
expl.cc:2:31: note: 'x::blah' declared here
  template struct blah { };
  ^
expl.cc:7:16: error: explicit instantiation of 'x::blah' must occur in
namespace 'x'
template class blah;
   ^
expl.cc:2:31: note: explicit instantiation refers here
  template struct blah { };
  ^
4 errors generated.

[Bug c++/88210] New: Add fix-it hint for explicit template instantiations

[redi at gcc dot gnu.org]

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

Bug ID: 88210
   Summary: Add fix-it hint for explicit template instantiations
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

namespace x {
  template struct blah { };
}

extern template class blah;

template class blah;


This produces:

expl.cc:5:23: error: 'blah' is not a class template
5 | extern template class blah;
  |   ^~~~
expl.cc:5:23: error: explicit instantiation of non-template type 'blah'
expl.cc:7:16: error: 'blah' is not a class template
7 | template class blah;
  |^~~~
expl.cc:7:16: error: explicit instantiation of non-template type 'blah'


It would be helpful to suggest x::blah instead of just saying "is not a class
template".

It took me a while to realise the problem here, because I've got used to GCC
now saying "did you mean x::blah?" when that's what the problem is.

[Bug target/88178] [9 Regression] ICE in dbx_reg_number, at dwarf2out.c:13659

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
Fixed for gcc-9, no backports planned.

[Bug target/88178] [9 Regression] ICE in dbx_reg_number, at dwarf2out.c:13659

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target|x86_64-unknown-linux-gnu|x86
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Uroš Bizjak  ---
Fixed for 9.0, no backport planned.
(In reply to Jakub Jelinek from comment #3)
> void foo (void)
> {
>   register int r19 asm ("19");
> }
> 
> ICEs with -g too.
> Similar effects with "16", "argp" or "frame".
> Guess it would be nice to reject these regs somewhere early, but there
> doesn't seem to be a target hook for that.  There is accessible_reg_set
> which only mips uses, wonder if we could make them unaccessible and what
> effect that would have.
> I think it removes those registers from operand_reg_set and thus they
> wouldn't be general_operand though.

It looks to me that accesible_reg_set is intended to disable registers when
certain ISA is not available. x86 disables registers by clearing their names,
in addition to setting fixed_reg flag on the register.

The registers that are now marked as IGNORED_DWARF_REGNUM can sneak to dwarf2
processing via invalid code paths, so they should be marked as ignored
nevertheless.

I'll play a bit with accessible_reg_set, maybe we can also disable unavailable
reg in a more elegant way than currently implemented. This is something to
consider after the release branch is branched, though.

[Bug target/88178] [9 Regression] ICE in dbx_reg_number, at dwarf2out.c:13659

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Nov 26 20:50:57 2018
New Revision: 266480

URL: https://gcc.gnu.org/viewcvs?rev=266480&root=gcc&view=rev
Log:
PR target/88178
* config/i386/i386.c (dbx_register_map): Use IGNORED_DWARF_REGNUM
for registers for which no debug information can be generated.
Use INVALID_REGNUM for non-existent registers.
(dbx64_register_map): Ditto.
(svr4_dbx_register_map): Ditto.

testsuite/ChangeLog:

PR target/88178
* gcc.target/pr88178.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr88178.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/88209] Inefficient array initialization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||avr
  Component|c++ |middle-end

--- Comment #1 from Andrew Pinski  ---
My bet this is a really target specific issue as the middle end usually uses
the target cost model if figure out if it should do a copy loop or a zeroing
loop.

[Bug c++/88209] New: Inefficient array initialization

[bseifert at gmx dot at]

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

Bug ID: 88209
   Summary: Inefficient array initialization
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bseifert at gmx dot at
  Target Milestone: ---

The following was tested on avr-gcc, but this behavior should not be different
on other platforms.

Consider the following array declaration with initialization of all elements to
0:

int main(void)
{
   char arr[256] = {0};
   return 0;
}

In avr-gcc 8.2.0 and before the following asm code is generated:

  9a:   de 01   movwr26, r28
  9c:   11 96   adiwr26, 0x01   ; 1
  9e:   80 e0   ldi r24, 0x00   ; 0
  a0:   91 e0   ldi r25, 0x01   ; 1
  a2:   fd 01   movwr30, r26
  a4:   9c 01   movwr18, r24
  a6:   11 92   st  Z+, r1
  a8:   21 50   subir18, 0x01   ; 1
  aa:   30 40   sbcir19, 0x00   ; 0
  ac:   e1 f7   brne.-8 ; 0xa6 

This behavior is what to expect. 256 Bytes of 0 (register r1) is pushed on the
stack.

In avr-gcc 9.0.0 (20181118) this code is generated. Here a 256-bytes data field
is generated in section .rodata
I don't fully understand the code because in the last three lines, still 0
(register r1) is pushed on the stack! 

  b0:   80 91 00 01 lds r24, 0x0100 ; 0x800100 <__data_start>
  b4:   90 91 01 01 lds r25, 0x0101 ; 0x800101 <__data_start+0x1>
  b8:   9a 83   std Y+2, r25; 0x02
  ba:   89 83   std Y+1, r24; 0x01
  bc:   fe 01   movwr30, r28
  be:   33 96   adiwr30, 0x03   ; 3
  c0:   8e ef   ldi r24, 0xFE   ; 254
  c2:   df 01   movwr26, r30
  c4:   1d 92   st  X+, r1
  c6:   8a 95   dec r24
  c8:   e9 f7   brne.-6 ; 0xc4 

In this case RAM is wated because of the 256 bytes reserved in .rodata
The examples were compiled with -Os. At first I was thinking this new behavior
is the result of some runtime optimization but for -Os, the focus should be
laid on code size / memory consumption. So I consider this as a bug!

[Bug testsuite/88208] New: new test case c-c++-common/builtin-has-attribute-3.c in r266335 has multiple excess errors

[seurer at gcc dot gnu.org]

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

Bug ID: 88208
   Summary: new test case c-c++-common/builtin-has-attribute-3.c
in r266335 has multiple excess errors
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This isn't specific to any target from looking at the test results email list.

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -Wc++-compat -Wall -ftrack-macro-expansion=0 -S -o
builtin-has-attribute-3.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:11:25:
error: alignment for 'faligned_1' must be at least 4
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:12:25:
error: alignment for 'faligned_2' must be at least 4
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:39:3:
error: alignment for '__builtin_has_attribute_tmp.' must be at least 4
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:40:3:
error: alignment for '__builtin_has_attribute_tmp.' must be at least 4
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:47:3:
error: alignment for '__builtin_has_attribute_tmp.' must be at least 4
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:48:3:
error: alignment for '__builtin_has_attribute_tmp.' must be at least 4
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:
In function 'test_aligned':
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:50:3:
error: size of array 'Assert' is negative
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:
At top level:
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:52:3:
error: alignment for '__builtin_has_attribute_tmp.' must be at least 4
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:
In function 'test_aligned':
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:52:3:
error: size of array 'Assert' is negative
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:
At top level:
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:53:3:
error: alignment for '__builtin_has_attribute_tmp.' must be at least 4
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:
In function 'test_aligned':
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:56:3:
error: size of array 'Assert' is negative
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:
At top level:
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:58:3:
error: alignment for '__builtin_has_attribute_tmp.' must be at least 4
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:59:3:
error: alignment for '__builtin_has_attribute_tmp.' must be at least 4
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:
In function 'test_aligned':
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:59:3:
error: size of array 'Assert' is negative
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:
At top level:
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:71:3:
warning: 'alloc_align' attribute ignored on a function returning 'void'
[-Wattributes]
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:82:3:
warning: 'alloc_size' attribute ignored on a function returning 'void'
[-Wattributes]
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:83:3:
warning: 'alloc_size' attribute ignored on a function returning 'void'
[-Wattributes]
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:30:33:
warning: 'falias' specifies less restrictive attribute than its target
'fnoreturn': 'noreturn' [-Wmissing-attributes]
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c:28:22:
note: 'falias' target declared here
compiler exited with status 1
PASS: c-c++-common/builtin-has-attribute-3.c  -Wc++-compat   (test for
warnings, line 71)
PASS: c-c++-common/builtin-has-attribute-3.c  -Wc++-compat   (test for
warnings, line 82)
PASS: c-c++-common/builtin-has-attribute-3.c  -Wc++-compat   (test for
warnings, line 83)
FAIL: c-c++-common/builtin-has-attribute-3.c  -Wc++-compat  (test for e

[Bug bootstrap/81033] [8 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces

[iains at gcc dot gnu.org]

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

--- Comment #50 from Iain Sandoe  ---
Author: iains
Date: Mon Nov 26 19:49:19 2018
New Revision: 266478

URL: https://gcc.gnu.org/viewcvs?rev=266478&root=gcc&view=rev
Log:
darwin - backport r263763 to fix PR81033

2018-11-26  Iain Sandoe  

Backport from mainline
2018-08-22  Iain Sandoe  

PR bootstrap/81033
PR target/81733
PR target/52795
* gcc/dwarf2out.c (FUNC_SECOND_SECT_LABEL): New.
(dwarf2out_switch_text_section): Generate a local label for the second
function sub-section and apply it as the second FDE start label.
* gcc/final.c (final_scan_insn_1): Emit second FDE label after the
second
sub-section start.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/dwarf2out.c
branches/gcc-7-branch/gcc/final.c

[Bug target/81733] stage1 libgcc_s.dylib fails to link on Darwin 11/x86_64

[iains at gcc dot gnu.org]

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

--- Comment #24 from Iain Sandoe  ---
Author: iains
Date: Mon Nov 26 19:49:19 2018
New Revision: 266478

URL: https://gcc.gnu.org/viewcvs?rev=266478&root=gcc&view=rev
Log:
darwin - backport r263763 to fix PR81033

2018-11-26  Iain Sandoe  

Backport from mainline
2018-08-22  Iain Sandoe  

PR bootstrap/81033
PR target/81733
PR target/52795
* gcc/dwarf2out.c (FUNC_SECOND_SECT_LABEL): New.
(dwarf2out_switch_text_section): Generate a local label for the second
function sub-section and apply it as the second FDE start label.
* gcc/final.c (final_scan_insn_1): Emit second FDE label after the
second
sub-section start.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/dwarf2out.c
branches/gcc-7-branch/gcc/final.c

[Bug target/52795] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE on {x86_64,i386}-apple-darwin{10,11} at -m64

[iains at gcc dot gnu.org]

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

--- Comment #14 from Iain Sandoe  ---
Author: iains
Date: Mon Nov 26 19:49:19 2018
New Revision: 266478

URL: https://gcc.gnu.org/viewcvs?rev=266478&root=gcc&view=rev
Log:
darwin - backport r263763 to fix PR81033

2018-11-26  Iain Sandoe  

Backport from mainline
2018-08-22  Iain Sandoe  

PR bootstrap/81033
PR target/81733
PR target/52795
* gcc/dwarf2out.c (FUNC_SECOND_SECT_LABEL): New.
(dwarf2out_switch_text_section): Generate a local label for the second
function sub-section and apply it as the second FDE start label.
* gcc/final.c (final_scan_insn_1): Emit second FDE label after the
second
sub-section start.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/dwarf2out.c
branches/gcc-7-branch/gcc/final.c

[Bug target/88207] [9 regression] gcc.target/i386/pr22076.c etc. FAIL

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #2 from Uroš Bizjak  ---
CC author of the mentioned revision.

[Bug target/88207] [9 regression] gcc.target/i386/pr22076.c etc. FAIL

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target|i?86-*-*, x86_64-*-*|i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-26
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
It is due to r266385, reported at [1]:

The PR22076 moves a value from mm0 via integer register to a volatile location:

movq.LC1, %mm0
paddb   .LC0, %mm0
movq%mm0, 16(%esp)
movl16(%esp), %eax
movl20(%esp), %edx
movl%eax, (%esp)
movl%edx, 4(%esp)
movq(%esp), %mm0
addl$28, %esp

where before the patch we had:

movq.LC1, %mm0
paddb   .LC0, %mm0
movq%mm0, 8(%esp)
movq8(%esp), %mm0
addl$20, %esp

In PR81563 the compiler now saves the value on stack, while before the patch,
call-saved register was allocated for a value that lives across the call.



[1] https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01975.html

[Bug testsuite/87486] [9 regression] gcc.target/powerpc/undef-bool-2.c fails starting with r264335

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from seurer at gcc dot gnu.org ---
This is fixed now.

[Bug c++/88184] [9 Regression] ICE on (invalid) C++ code when compiled with -std=c++2a: unexpected expression ‘f’ of kind template_id_expr

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Interesting that on both my computers I see

$ ./cc1plus -quiet 88184.C -std=c++2a
88184.C: In function ‘void g()’:
88184.C:10:12: error: no matching function for call to ‘f()’
   10 |   f < T > ();
  |^


(No local patches applied.)

[Bug c/57182] Documentation implies -fprofile-arcs required to create .text.unlikely sections

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||sandra at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from sandra at gcc dot gnu.org ---
Fixed on trunk.

[Bug c/57182] Documentation implies -fprofile-arcs required to create .text.unlikely sections

[sandra at gcc dot gnu.org]

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

--- Comment #3 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Mon Nov 26 18:22:19 2018
New Revision: 266473

URL: https://gcc.gnu.org/viewcvs?rev=266473&root=gcc&view=rev
Log:
2018-11-26  Sandra Loosemore  

PR c/57182

gcc/
* doc/invoke.texi (Optimize Options): Document that
-freorder-functions also uses "hot" and "cold" attributes.

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

[Bug fortran/88206] [7/8/9 Regression] ICE in gfc_match_type_spec, at fortran/match.c:2229

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-26
  Known to work||6.5.0
 Ever confirmed|0   |1
  Known to fail||7.3.0, 8.2.0, 9.0

--- Comment #1 from Dominique d'Humieres  ---
The change appeared between revisions r241433 (2016-10-21, OK) and r241509
(2016-10-25, ICE).

[Bug target/88207] [9 regression] gcc.target/i386/pr22076.c etc. FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug target/88207] New: [9 regression] gcc.target/i386/pr22076.c etc. FAIL

[ro at gcc dot gnu.org]

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

Bug ID: 88207
   Summary: [9 regression] gcc.target/i386/pr22076.c etc. FAIL
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i?86-*-*, x86_64-*-*

Between 20181123 (r266403) and 20181124 (r266429), two tests regressed on
32-bit
x86 (seen on i386-pc-solaris2.11, also reports for i586-unknown-freebsd11.2,
i686-pc-linux-gnu, x86_64-pc-linux-gnu:

+FAIL: gcc.target/i386/pr22076.c scan-assembler-not movl

+FAIL: gcc.target/i386/pr81563.c scan-assembler-times movl[t
]*-4(%ebp),[t ]*%edi 1
+FAIL: gcc.target/i386/pr81563.c scan-assembler-times movl[t
]*-8(%ebp),[t ]*%esi 1

[Bug other/16615] throughout gcc docu and code numerous "can not"'s appear

[joseph at codesourcery dot com]

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

--- Comment #9 from joseph at codesourcery dot com  ---
I'd suggest reviewing the set of files changed to see if any are generated 
files, or their sources (configure.ac, aclocal.m4, etc.), and doing a 
regeneration in that case.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[robert.simpson.lists at gmail dot com]

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

Robert J. Simpson  changed:

   What|Removed |Added

 CC||robert.simpson.lists@gmail.
   ||com

--- Comment #34 from Robert J. Simpson  
---
Appears to still be an issue in gcc-8:

gcc 8.2.0

#pragma GCC diagnostic ignored "-Wcomment"
// multi-line comment \
// 

../canvas.cpp:85:1: warning: multi-line comment [-Wcomment]
 // multi-line comment \
 ^

[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
See rs6000.c:validate_condition_mode.  This is:

r36191 (from 2000), original;
r39610 (from 2001), -ffast-math;
r40300 (from 2001), -funsafe-math-optimizations;
r55904 (from 2002), -ffinite-math-only.

So it took some time to get it to this, but that is all ages ago.

Should there be UNLT during gimple, even with -ffinite-math-only?  Should
expand then convert that do something saner already?  Or should it not be
generated in gimple either?

[Bug fortran/88206] New: [7/8/9 Regression] ICE in gfc_match_type_spec, at fortran/match.c:2229

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

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

Bug ID: 88206
   Summary: [7/8/9 Regression] ICE in gfc_match_type_spec, at
fortran/match.c:2229
   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: ---

Affects versions 7,8,9 :


$ cat z1.f90
program p
   integer, parameter :: z(4) = [1,2,3,4]
   integer :: k = 2
   print *, [real(z(k))]
end


$ gfortran-6 -c z1.f90
$
$ gfortran-9-20181125 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb2bcff crash_signal
../../gcc/toplev.c:326
0x64ba3f gfc_match_type_spec(gfc_typespec*)
../../gcc/fortran/match.c:2229
0x5ed6b0 gfc_match_array_constructor(gfc_expr**)
../../gcc/fortran/array.c:1151
0x650f29 match_primary
../../gcc/fortran/matchexp.c:153
0x650f29 match_level_1
../../gcc/fortran/matchexp.c:211
0x650f29 match_mult_operand
../../gcc/fortran/matchexp.c:267
0x651188 match_add_operand
../../gcc/fortran/matchexp.c:356
0x6513dc match_level_2
../../gcc/fortran/matchexp.c:480
0x651532 match_level_3
../../gcc/fortran/matchexp.c:551
0x651624 match_level_4
../../gcc/fortran/matchexp.c:599
0x651624 match_and_operand
../../gcc/fortran/matchexp.c:693
0x651812 match_or_operand
../../gcc/fortran/matchexp.c:722
0x6518e2 match_equiv_operand
../../gcc/fortran/matchexp.c:765
0x6519b4 match_level_5
../../gcc/fortran/matchexp.c:811
0x650d91 gfc_match_expr(gfc_expr**)
../../gcc/fortran/matchexp.c:870
0x6398d3 match_io_element
../../gcc/fortran/io.c:3587
0x63c245 match_io_list
../../gcc/fortran/io.c:3626
0x63c654 match_io
../../gcc/fortran/io.c:4287
0x63fe5a gfc_match_print()
../../gcc/fortran/io.c:4344
0x66b341 match_word
../../gcc/fortran/parse.c:65

[Bug fortran/78892] [7.0 Regression] no type conversion before coarray put

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

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

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

Related to pr66681, with option -finit-local-zero or -finit-real :


$ cat z1.f90
program p
  real :: a[*]
  integer :: i
  if ( this_image() == 1 ) then
do i = 1, num_images()
  a[i] = i
end do
  end if
end


$ cat z2.f90
program p
   real :: a[*]
   a[this_image()] = this_image()
end


$ cat z3.f90
program p
   real :: a[*]
   a = this_image()
end


$ gfortran-9-20181125 -c z1.f90 -fcoarray=lib
$
$ gfortran-9-20181125 -c z1.f90 -fcoarray=lib -finit-local-zero
z1.f90:2:0:

2 |   real :: a[*]
  |
internal compiler error: in fold_convert_loc, at fold-const.c:2426
0x8ab5f7 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2425
0x6ee4b5 gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:9063
0x6fe7ed gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10449
0x6c1135 trans_code
../../gcc/fortran/trans.c:1837
0x6e88d4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6509
0x675026 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x675026 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6bdaff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/70817] Internal compiler error coarrays -finit-real=snan

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

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

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

Related to pr66681, with option -finit-local-zero or -finit-real :


$ cat z1.f90
program f
   real, parameter :: zero = 0.0
   real :: p[*]
   p = zero
end program


$ cat z2.f90
program f
   real :: p[*]
   p = 0.0
end


$ gfortran-9-20181125 -c z1.f90 -fcoarray=lib
$
$ gfortran-9-20181125 -c z1.f90 -fcoarray=lib -finit-local-zero
z1.f90:3:0:

3 |real :: p[*]
  |
internal compiler error: in fold_convert_loc, at fold-const.c:2426
0x8ab5f7 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2425
0x6ee4b5 gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:9063
0x6fe7ed gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10449
0x6c1135 trans_code
../../gcc/fortran/trans.c:1837
0x6e88d4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6509
0x675026 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x675026 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6bdaff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/88205] New: ICE in gfc_wide_strncasecmp, at fortran/scanner.c:249

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

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

Bug ID: 88205
   Summary: ICE in gfc_wide_strncasecmp, at fortran/scanner.c:249
   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: ---

With a non-scalar-default-char-expr, down to at least gcc-5 :


$ cat z1.f90
subroutine s
   real, parameter :: status = 0
   open (newunit=n, status=status)
end


$ cat z2.f90
subroutine s
   complex, parameter :: status = 0
   open (newunit=n, status=status)
end


$ cat z3.f90
program p
  logical, parameter :: status = .false.
  open (newunit=a, status=status)
end


$ gfortran-9-20181125 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb2bcff crash_signal
../../gcc/toplev.c:326
0x6959fb gfc_wide_strncasecmp(unsigned int const*, char const*, unsigned long)
../../gcc/fortran/scanner.c:249
0x63eb4b gfc_match_open()
../../gcc/fortran/io.c:2165
0x66b341 match_word
../../gcc/fortran/parse.c:65
0x66f2b5 decode_statement
../../gcc/fortran/parse.c:531
0x66f6aa next_free
../../gcc/fortran/parse.c:1234
0x66f6aa next_statement
../../gcc/fortran/parse.c:1466
0x670cbb parse_spec
../../gcc/fortran/parse.c:3858
0x673787 parse_progunit
../../gcc/fortran/parse.c:5671
0x6751bc gfc_parse_file()
../../gcc/fortran/parse.c:6218
0x6bdaff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/66681] [Coarray] Wrong result in assigning this_image() to a complex coarray

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

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #12 from G. Steinmetz  ---

Update, with option -finit-local-zero or -finit-real :


$ cat pr66681.f90
   complex a[*]
   a = this_image()
end


$ cat z1.f90
program p
   complex :: a[*]
   a = 1.0
end


$ cat z2.f90
program p
   real :: a[*]
   a = 1.0
end


$ gfortran-9-20181125 -c pr66681.f90 -fcoarray=lib
$
$ gfortran-9-20181125 -c pr66681.f90 -fcoarray=lib -finit-local-zero
pr66681.f90:1:0:

1 |complex a[*]
  |
internal compiler error: in fold_convert_loc, at fold-const.c:2426
0x960e24 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2425
0x725654 gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:9101
0x737c9d gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10449
0x6e7c15 trans_code
../../gcc/fortran/trans.c:1837
0x71d18d gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6509
0x69a8b6 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x69a8b6 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6e3eef gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug c++/86900] [8/9 Regression] -gdwarf-5 -O2 -ffunction-sections = assembler error

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug other/88204] New: New test case 26_numerics/complex/operators/more_constexpr.cc from r266416 fails

[seurer at gcc dot gnu.org]

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

Bug ID: 88204
   Summary: New test case
26_numerics/complex/operators/more_constexpr.cc from
r266416 fails
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I see this on all the powerpc64 targets I test on.


spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/./gcc/xg++ -shared-libgcc
-B/home/seurer/gcc/build/gcc-test2/./gcc -nostdinc++
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/lib/ -isystem
/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/include -isystem
/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/sys-include
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util
/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/26_numerics/complex/operators/more_constexpr.cc
-std=gnu++2a -fno-diagnostics-show-caret -fdiagnostics-color=never -S -o
more_constexpr.s
/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/26_numerics/complex/operators/more_constexpr.cc:
In instantiation of 'void __gnu_test::test_operators() [with _Tp = long
double]':
/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/26_numerics/complex/operators/more_constexpr.cc:59:
  required from here
/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/26_numerics/complex/operators/more_constexpr.cc:41:
  in 'constexpr' expansion of 'std::operator/(a, c)'
/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/complex:429:
  in 'constexpr' expansion of '#'result_decl' not supported by
dump_expr#.std::complex::operator/=(((long
double)__y))'
/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/26_numerics/complex/operators/more_constexpr.cc:41:
error: '(1.0e+0l / 5.0e+0l)' is not a constant expression
compiler exited with status 1
FAIL: 26_numerics/complex/operators/more_constexpr.cc (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/26_numerics/complex/operators/more_constexpr.cc:41:
  in 'constexpr' expansion of 'std::operator/(a, c)'
/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/complex:429:
  in 'constexpr' expansion of '#'result_decl' not supported by
dump_expr#.std::complex::operator/=(((long
double)__y))'
/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/26_numerics/complex/operators/more_constexpr.cc:41:
error: '(1.0e+0l / 5.0e+0l)' is not a constant expression

[Bug c++/88203] assert does not compile with OpenMP's pragma omp parallel for default(none)

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

   Keywords||openmp
 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
It's tricky to use macro-expanded expressions in scope of default(none), you
never know what the expansion is going to reference. This is not limited to the
assert macro (or to its use of __PRETTY_FUNCTION__).

In general I'm afraid use of default(none) needs introducing wrappers for
anything that can be macro-expanded in an unknown way, and relying on inlining
to optimize it back. Unfortunately though, for assert that implies almost
reimplementing it to get file:line info as in original code.

I'm not sure there's a compiler bug here. Just a painful side of default(none).

[Bug c++/87947] Symbol Does Not Appear in Object File

[comm+gnu at squotd dot net]

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

--- Comment #5 from comm+gnu at squotd dot net ---
OK, thanks. I appreciate the explanation.

[Bug c++/88203] New: assert does not compile with OpenMP's pragma omp parallel for default(none)

[zkoza at ift dot uni.wroc.pl]

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

Bug ID: 88203
   Summary: assert does not compile with OpenMP's pragma omp
parallel for default(none)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zkoza at ift dot uni.wroc.pl
  Target Milestone: ---

Desription:

It is impossible to use assertions in OpenMP-controlled for loops if
default(none) is added as an option controlling the OpenMP loop compilation 


The program:

#include  

int main()
{
#pragma omp parallel for default(none) 
  for (int i = 0; i < 10; i++)
  {
assert (i < 10);
  }
}


=

Compilation:
g++ main.cpp -fopenmp

(adding -std=c++11, 14, 17 does not help)

=
Output:

In file included from /usr/include/c++/8.2.1/cassert:44,
 from main.cpp:1:
main.cpp: In function ‘int main()’:
main.cpp:8:5: error: ‘__PRETTY_FUNCTION__’ not specified in enclosing
‘parallel’
 assert (i < 10);
 ^~
main.cpp:5:9: error: enclosing ‘parallel’
 #pragma omp parallel for default(none)
 ^~~

==
compiler:
gcc -v
Using built-in specs.
COLLECT_GCC=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 20180831 (GCC) 


system:
manjaro  linux 

uname -a
Linux Zbyszek 4.14.81-1-MANJARO #1 SMP PREEMPT Tue Nov 13 22:12:35 UTC 2018
x86_64 GNU/Linux

[Bug c++/87075] [7/8/9 Regression] ICE when compiling the test suite of GLM 0.9.9.0

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Mon Nov 26 15:53:43 2018
New Revision: 266468

URL: https://gcc.gnu.org/viewcvs?rev=266468&root=gcc&view=rev
Log:
PR c++/87075 - ICE with constexpr array initialization.

My patch of 2016-08-26 to avoid calling a trivial default constructor
introduced TARGET_EXPRs initialized with void_node to express trivial
initialization.  But when this shows up in a VEC_INIT_EXPR, we weren't
prepared to handle it.  Fixed by handling it explicitly in
cxx_eval_vec_init_1.

* constexpr.c (cxx_eval_vec_init_1): Handle trivial initialization.

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

[Bug c++/84281] Heap grows indefinitely

[jason at gcc dot gnu.org]

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

--- Comment #14 from Jason Merrill  ---
Author: jason
Date: Mon Nov 26 15:53:48 2018
New Revision: 266469

URL: https://gcc.gnu.org/viewcvs?rev=266469&root=gcc&view=rev
Log:
PR c++/84281

2018-02-12  Richard Biener  

* constexpr.c (cxx_eval_vec_init_1): Use a RANGE_EXPR to compact
uniform constructors and delay allocating them fully.

Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/constexpr.c

[Bug tree-optimization/88182] [9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6465

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/88182] [9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6465

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Nov 26 15:37:35 2018
New Revision: 266467

URL: https://gcc.gnu.org/viewcvs?rev=266467&root=gcc&view=rev
Log:
2018-11-26  Richard Biener  

PR tree-optimization/88182
* tree-vect-loop.c (vectorizable_reduction): Pick up single
correct reduc_def_info.
* tree-vect-slp.c (vect_analyze_slp_instance): Set
STMT_VINFO_REDUC_DEF of the first stmt.

libgomp/
* testsuite/libgomp.c++/pr88182.C: New testcase.

Added:
trunk/libgomp/testsuite/libgomp.c++/pr88182.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-slp.c
trunk/libgomp/ChangeLog

[Bug c++/88184] [9 Regression] ICE on (invalid) C++ code when compiled with -std=c++2a: unexpected expression ‘f’ of kind template_id_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug go/88202] New: FAIL: runtime/pprof

[sch...@linux-m68k.org]

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

Bug ID: 88202
   Summary: FAIL: runtime/pprof
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: sch...@linux-m68k.org
CC: cmang at google dot com
  Target Milestone: ---
Target: aarch64-*-*

--- FAIL: TestCPUProfile (6.84s)
pprof_test.go:254: total 19 CPU profile samples collected:
17: 0x4db918 (runtime.sigprof:3553) 0x4f23bb (runtime.sighandler:40)
0x4f23bb (runtime.sighandler:40) 0xf7e005db (:0) 0x405da0 (pprof.cpuHog1:55)
0x405d53 (pprof.cpuHogger:38) 0x405edf (pprof.TestCPUProfile..func1:86)
0x40651f (pprof.testCPUProfile:178) 0x405eaf (runtime/pprof.TestCPUProfile:85)
0x537fe7 (testing.tRunner:827)

2: 0x4db918 (runtime.sigprof:3553) 0x4f23bb (runtime.sighandler:40)
0x4f23bb (runtime.sighandler:40) 0xf7e005db (:0) 0x405db0 (pprof.cpuHog1:53)
0x405d53 (pprof.cpuHogger:38) 0x405edf (pprof.TestCPUProfile..func1:86)
0x40651f (pprof.testCPUProfile:178) 0x405eaf (runtime/pprof.TestCPUProfile:85)
0x537fe7 (testing.tRunner:827)

pprof_test.go:277: found 19 samples in avoid-function runtime.sigprof
pprof_test.go:289: pprof.cpuHog1: 19
pprof_test.go:187: retrying with 400ms duration
pprof_test.go:254: total 32 CPU profile samples collected:
31: 0x4db918 (runtime.sigprof:3553) 0x4f23bb (runtime.sighandler:40)
0x4f23bb (runtime.sighandler:40) 0xf7e005db (:0) 0x405da0 (pprof.cpuHog1:55)
0x405d53 (pprof.cpuHogger:38) 0x405edf (pprof.TestCPUProfile..func1:86)
0x40651f (pprof.testCPUProfile:178) 0x405eaf (runtime/pprof.TestCPUProfile:85)
0x537fe7 (testing.tRunner:827)

1: 0x4db918 (runtime.sigprof:3553) 0x4f23bb (runtime.sighandler:40)
0x4f23bb (runtime.sighandler:40) 0xf7e005db (:0) 0x405db0 (pprof.cpuHog1:53)
0x405d53 (pprof.cpuHogger:38) 0x405edf (pprof.TestCPUProfile..func1:86)
0x40651f (pprof.testCPUProfile:178) 0x405eaf (runtime/pprof.TestCPUProfile:85)
0x537fe7 (testing.tRunner:827)

pprof_test.go:277: found 32 samples in avoid-function runtime.sigprof
pprof_test.go:289: pprof.cpuHog1: 32
pprof_test.go:187: retrying with 800ms duration
pprof_test.go:254: total 47 CPU profile samples collected:
42: 0x4db918 (runtime.sigprof:3553) 0x4f23bb (runtime.sighandler:40)
0x4f23bb (runtime.sighandler:40) 0xf7e005db (:0) 0x405da0 (pprof.cpuHog1:55)
0x405d53 (pprof.cpuHogger:38) 0x405edf (pprof.TestCPUProfile..func1:86)
0x40651f (pprof.testCPUProfile:178) 0x405eaf (runtime/pprof.TestCPUProfile:85)
0x537fe7 (testing.tRunner:827)

1: 0x4db918 (runtime.sigprof:3553) 0x4f23bb (runtime.sighandler:40)
0x4f23bb (runtime.sighandler:40) 0xf7e005db (:0) 0xf7beebbc (:0) 0x41d2b7
(runtime.usleep:58) 0x4eb3a3 (runtime.sysmon:4032) 0x4f1aeb
(runtime.mstart1:1235) 0x41ce2f (runtime_mstart:545)

3: 0x4db918 (runtime.sigprof:3553) 0x4f23bb (runtime.sighandler:40)
0x4f23bb (runtime.sighandler:40) 0xf7e005db (:0) 0x405db0 (pprof.cpuHog1:53)
0x405d53 (pprof.cpuHogger:38) 0x405edf (pprof.TestCPUProfile..func1:86)
0x40651f (pprof.testCPUProfile:178) 0x405eaf (runtime/pprof.TestCPUProfile:85)
0x537fe7 (testing.tRunner:827)

1: 0x4db918 (runtime.sigprof:3553) 0x4f23bb (runtime.sighandler:40)
0x4f23bb (runtime.sighandler:40) 0xf7e005db (:0) 0xf7c033f8 (:0) 0x56f3e3
(runtime.nanotime:19) 0x4ead37 (runtime.notetsleep_internal:213) 0x4eae4f
(runtime.notetsleep:228) 0x4ec18f (runtime.forEachP:1428) 0x4ec18f
(runtime.forEachP:1428) 0x4bf19f (runtime.systemstack..func1:63) 0x41ce17
(runtime_mstart:527)

pprof_test.go:277: found 47 samples in avoid-function runtime.sigprof
pprof_test.go:289: pprof.cpuHog1: 45
pprof_test.go:187: retrying with 1.6s duration
pprof_test.go:254: total 95 CPU profile samples collected:
87: 0x4db918 (runtime.sigprof:3553) 0x4f23bb (runtime.sighandler:40)
0x4f23bb (runtime.sighandler:40) 0xf7e005db (:0) 0x405da0 (pprof.cpuHog1:55)
0x405d53 (pprof.cpuHogger:38) 0x405edf (pprof.TestCPUProfile..func1:86)
0x40651f (pprof.testCPUProfile:178) 0x405eaf (runtime/pprof.TestCPUProfile:85)
0x537fe7 (testing.tRunner:827)

6: 0x4db918 (runtime.sigprof:3553) 0x4f23bb (runtime.sighandler:40)
0x4f23bb (runtime.sighandler:40) 0xf7e005db (:0) 0x405db0 (pprof.cpuHog1:53)
0x405d53 (pprof.cpuHogger:38) 0x405edf (pprof.TestCPUProfile..func1:86)
0x40651f (pprof.testCPUProfile:178) 0x405eaf (runtime/pprof.TestCPUProfile:85)
0x537fe7 (testing.tRunner:827)

1: 0x4db918 (runtime.sigprof:3553) 0x4f23bb (runtime.sighandler:40)
0x4f23bb (runtime.sighandler:40) 0xf7e005db (:0) 0x405d60 (pprof.cpuHogger:37)
0x405edf (pprof.TestCPUProfile..func1:86) 0x40651f (pprof.testCPUProfile:178)
0x405eaf (runtime/pprof.TestCPUProfile:85) 0x537fe7 (testing.tRunner:827)

1: 0x4db918 (runtime.sigprof:3553) 0x4f23bb (runtime.sighandler:40)
0x4f23bb (runtime.sighandler:40) 

[Bug middle-end/88175] Showing header file instead of source code line for uninitialized variable

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Attachment #45077|0   |1
is obsolete||

--- Comment #12 from Jonathan Wakely  ---
Created attachment 45096
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45096&action=edit
Preprocessed testcase

I'm attaching the preprocessed testcase, which produces exactly the same
output. Please do that next time, instead of a zip file with multiple sources.
See https://gcc.gnu.org/bugs/ for the bug submission policies.

[Bug middle-end/88175] Showing header file instead of source code line for uninitialized variable

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Jonny Grant from comment #8)
> Do you agree this warning output should be changed to clarify?

Yes, there's plenty of room to improve it.

> I understand your reply about it being non-POD when a C++ STL string is
> added. Which adds the implicitly-defined copy constructor. Should it not say
> "implicitly-defined copy constructor for 'struct info'"? instead of "this
> function" ?

That might be an improvement, but may not be easy to do. I doubt the code
generating that warning knows it's in an implicitly-defined member.

> Think also better for GCC to show the typedef 'info_t' - would you agree?

No, I don't think so.

What's the point in that typedef anyway?


(In reply to Jonny Grant from comment #10)
> I wonder if the "POD" location of the struct

What does that mean?

[Bug c++/88201] New: lambda function fails to compile, when deactivated by a constexpr and deduced return type

[j.tourscher at alpi dot fr]

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

Bug ID: 88201
   Summary: lambda function fails to compile, when deactivated by
a constexpr and deduced return type
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: j.tourscher at alpi dot fr
  Target Milestone: ---

Created attachment 45095
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45095&action=edit
preprocessed test file

Hello, 

I have a compilation error when trying to compile code using a lambda function
that is deactivated by a "if constexpr". 
The code fails to compile when the lambda has a deduced return type, and is
stored inside a std::function or a C function pointer. 
But when re-enabling the constexpr condition, or specifiyng a return type for
the lambda, the code compiles.

code that produces the error : 

int main(int , char* [])
{
int (*f)() ; 

if constexpr (false)
f = [](){ return 0; };

return 0;
}

command line to compile the test : 
gcc test.cpp -o test -lstdc++ -std=c++17 -Wall -Wextra --save-temps

output from gcc :
test.cpp: In function ‘int main(int, char**)’:
test.cpp:6:30: error: invalid user-defined conversion from ‘main(int,
char**)::’ to ‘int (*)()’ [-fpermissive]
 f = [](){ return 0; };
  ^
test.cpp:6:16: note: candidate is: ‘constexpr main(int,
char**)operator void (*)()() const’ 
 f = [](){ return 0; };
^
test.cpp:6:16: note:   no known conversion from ‘void (*)()’ to ‘int (*)()’


comments : 
 - changing "constexpr (false)" to "constexpr (true)" makes the compilation to
succeed
 - changing "f = []() { return 0; };" to "f = []() -> int { return 0; };" makes
the compilation to succeed
 - the code compiles well with clang 6.0, or with msvc.
 - using  "std::function" instead of function pointer produces the
same error

gcc -v output : 
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 8.2.1 20181105 (Red Hat 8.2.1-5) (GCC) 

Regards

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type" and "associate"

[trnka at scm dot com]

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

--- Comment #6 from Tomáš Trnka  ---
The above is from GNU Fortran (GCC) 8.2.1 20181126

[Bug c++/88181] [7/8/9 Regression] ICE: verify_type failed (error: type variant differs by TYPE_PACKED)

[jakub at gcc dot gnu.org]

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

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

This untested patch fixed the ICE for me.

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type" and "associate"

[trnka at scm dot com]

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

--- Comment #5 from Tomáš Trnka  ---
Could you please kindly suggest what do I need to do to get this out of
WAITING? I will gladly assist with any debugging and testing, but I'm not well
versed enough with GCC internals to fix the underlying issue myself.

Looks like reallocation is also broken inside "associate" constructs. The
following testcase from pr85954 crashes (when compiled without optimization)
because no allocation code is generated at all. 

$ cat pr85954-z1.f90
program p
   character(:), allocatable :: z(:)
   call s(z)
contains
   subroutine s(x)
  character(:), allocatable :: x(:)
  associate (y => x)
 y = ['abc']
  end associate
  print *, allocated(x), size(x), len(x), x
   end
end
$ gfortran -g -fdump-tree-original pr85954-z1.f90 
$ grep alloc pr85954-z1.f90.003t.original 
$ ./a.out 
 F   0  1002358272
$ ./a.out  

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7fed77d6471e in ???
#1  0x7fed77d638d3 in ???
#2  0x7fed779d55bf in ???
#3  0x7fed77afef0d in ???
#4  0x4012d8 in s
at /home/trnka/adf/test/gcc-lhs-realloc-87937/pr85954-z1.f90:8
#5  0x401498 in p
at /home/trnka/adf/test/gcc-lhs-realloc-87937/pr85954-z1.f90:3
#6  0x4014ce in main
at /home/trnka/adf/test/gcc-lhs-realloc-87937/pr85954-z1.f90:3
Segmentation fault (core dumped)

The issue is less evident at -O1 and above, although the generated code is just
as incorrect. It just doesn't segfault that much but valgrind shows a lot of
uninitialized value errors all over the place.

The variant without an "associate" construct (z2.f90 in pr85954) works fine.

[Bug fortran/40196] [F03] [F08] Type parameter inquiry (str%len, a%kind) and Complex parts (z%re, z%im)

[manfred99 at gmx dot ch]

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

Manfred Schwarb  changed:

   What|Removed |Added

 CC||manfred99 at gmx dot ch

--- Comment #15 from Manfred Schwarb  ---
Paul, these three tests fail for me on x86 (32bit) since you
introduced them (x86_64 is OK). Unfortunately, the error message is not
really helpful:

f951: internal compiler error: Segmentation fault
0x838c18c ???
../sysdeps/i386/elf/start.S:119
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


The compiler barfs at all of the following lines, in the very same way:

inquiry_type_ref_1.f08:
  REAL, parameter :: rc = zc%re
  REAL, parameter :: ic = zc%im
  if (str%kind .ne. kind (str)) stop 6

inquiry_type_ref_2.f90:
   a%len = 2   ! { dg-error "Fortran 2003: LEN part_ref" }
   i = a%kind  ! { dg-error "Fortran 2003: KIND part_ref" }

inquiry_type_ref_3.f90:
   a%kind = 2! { dg-error "Assignment to a constant expression" }


As already told, x86_64 is OK. No idea if this is specific to my compile
setting. The rest of the test-suite passes more or less OK for me, so ...

[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Ok, I've updated slightly the micro-benchmark and I see following difference:
https://github.com/marxin/microbenchmark/tree/retpoline-table

on my Haswell desktop:

./test
no jump table: 4265908653
jump table   : 5118680921 (119.99%)

which is quite small I would say..

[Bug tree-optimization/87645] [7 Regression] gcc hangs up on vr_values::vrp_visit_assignment_or_call

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Mon Nov 26 14:16:01 2018
New Revision: 266461

URL: https://gcc.gnu.org/viewcvs?rev=266461&root=gcc&view=rev
Log:
2018-10-19  Richard Biener  

PR middle-end/87645
Backport from mainline
2018-07-12  Richard Biener  

* gimple-match-head.c (gimple_resimplify1): Apply recursion
limit.
(gimple_resimplify2): Likewise.
(gimple_resimplify3): Likewise.
(gimple_resimplify4): Likewise.

* gcc.dg/torture/pr87645.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr87645.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/gimple-match-head.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/87645] [7 Regression] gcc hangs up on vr_values::vrp_visit_assignment_or_call

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.3.1
 Resolution|--- |FIXED
  Known to fail|7.3.1   |7.3.0

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

[Bug target/88195] misleading error message for unsupported builtin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

That is because the recent def_builtin2 change made it diverge from what
def_builtin is doing, in particular if it needs ISA_64BIT, but !TARGET_64BIT,
return NULL immediately rather than trying to register something.  Unlike other
ISA options, -m64 vs. -m32 vs. -mx32 can't be changed through target attributes
and so there is no point deferring for later or registering right away.

[Bug middle-end/88175] Showing header file instead of source code line for uninitialized variable

[jg at jguk dot org]

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

--- Comment #10 from Jonny Grant  ---
I wonder if the "POD" location of the struct is also still recorded? In which
case could just output that.. rather than the implicitly defined
copy-constructor.

[Bug ada/88191] [9 Regression] ada bootstrap failure on alpha-linux-gnu ("SIGSYS" not declared in "Linux")

[doko at debian dot org]

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

Matthias Klose  changed:

   What|Removed |Added

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

--- Comment #4 from Matthias Klose  ---
fixed.

[Bug ada/88200] New: [9 Regression] ada bootstrap failure on alpha-linux-gnu (aised STORAGE_ERROR : stack overflow or erroneous memory access)

[doko at debian dot org]

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

Bug ID: 88200
   Summary: [9 Regression] ada bootstrap failure on
alpha-linux-gnu (aised STORAGE_ERROR : stack overflow
or erroneous memory access)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen with r266459, trying to build a cross compiler on x86_64-linux-gnu,
targeting alpha-linux-gnu:

/home/packages/cross/9/p/gcc-cross-ports/gcc/build/./gcc/xgcc
-B/home/packages/cross/9/p/gcc-cross-ports/gcc/build/./gcc/ -
B/usr/alpha-linux-gnu/bin/ -B/usr/alpha-linux-gnu/lib/ -isystem
/usr/alpha-linux-gnu/include -isystem /usr/alpha-linux-gnu/
sys-include -isystem
/home/packages/cross/9/p/gcc-cross-ports/gcc/build/sys-include-c -g -O2  
-W -Wall -gnatpg -nostdi
nc  -gnatn  s-secsta.adb -o s-secsta.o

raised STORAGE_ERROR : stack overflow or erroneous memory access
make[8]: *** [../gcc-interface/Makefile:299: s-secsta.o] Error 1

[Bug ada/88191] [9 Regression] ada bootstrap failure on alpha-linux-gnu ("SIGSYS" not declared in "Linux")

[doko at gcc dot gnu.org]

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

--- Comment #3 from Matthias Klose  ---
Author: doko
Date: Mon Nov 26 13:30:50 2018
New Revision: 266459

URL: https://gcc.gnu.org/viewcvs?rev=266459&root=gcc&view=rev
Log:
2018-11-26  Matthias Klose 

PR ada/88191
* libgnarl/s-linux__alpha.ads: Define SIGSYS.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/libgnarl/s-linux__alpha.ads

[Bug tree-optimization/87745] [9 regression] ICE in get_later_stmt, at tree-vectorizer.h:1109

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Mon Nov 26 13:31:21 2018
New Revision: 266460

URL: https://gcc.gnu.org/viewcvs?rev=266460&root=gcc&view=rev
Log:
2018-11-26  Richard Biener  

Backport from mainline
2018-10-15  Richard Biener  

PR middle-end/87610
* tree-ssa-structalias.c (struct vls_data): Add escaped_p member.
(visit_loadstore): When a used restrict tag escaped verify that
the points-to solution of "other" pointers do not include
escaped.
(compute_dependence_clique): If a used restrict tag escaped
communicated that down to visit_loadstore.

* gcc.dg/torture/restrict-6.c: New testcase.

2018-10-25  Richard Biener  

PR tree-optimization/87665
PR tree-optimization/87745
* tree-vectorizer.h (get_earlier_stmt): Remove.
(get_later_stmt): Pick up UID from the original non-pattern stmt.

* gfortran.dg/20181025-1.f: New testcase.

2018-10-24  Richard Biener  

PR tree-optimization/87665
* tree-vect-data-refs.c (vect_preserves_scalar_order_p): Adjust
to reflect reality.

* gcc.dg/torture/pr87665.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr87665.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/restrict-6.c
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/20181025-1.f
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-ssa-structalias.c
branches/gcc-7-branch/gcc/tree-vect-data-refs.c
branches/gcc-7-branch/gcc/tree-vectorizer.h

[Bug tree-optimization/87665] [7 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener  ---
Author: rguenth
Date: Mon Nov 26 13:31:21 2018
New Revision: 266460

URL: https://gcc.gnu.org/viewcvs?rev=266460&root=gcc&view=rev
Log:
2018-11-26  Richard Biener  

Backport from mainline
2018-10-15  Richard Biener  

PR middle-end/87610
* tree-ssa-structalias.c (struct vls_data): Add escaped_p member.
(visit_loadstore): When a used restrict tag escaped verify that
the points-to solution of "other" pointers do not include
escaped.
(compute_dependence_clique): If a used restrict tag escaped
communicated that down to visit_loadstore.

* gcc.dg/torture/restrict-6.c: New testcase.

2018-10-25  Richard Biener  

PR tree-optimization/87665
PR tree-optimization/87745
* tree-vectorizer.h (get_earlier_stmt): Remove.
(get_later_stmt): Pick up UID from the original non-pattern stmt.

* gfortran.dg/20181025-1.f: New testcase.

2018-10-24  Richard Biener  

PR tree-optimization/87665
* tree-vect-data-refs.c (vect_preserves_scalar_order_p): Adjust
to reflect reality.

* gcc.dg/torture/pr87665.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr87665.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/restrict-6.c
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/20181025-1.f
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-ssa-structalias.c
branches/gcc-7-branch/gcc/tree-vect-data-refs.c
branches/gcc-7-branch/gcc/tree-vectorizer.h

[Bug middle-end/87610] [7 Regression] wrong-code with restrict

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Mon Nov 26 13:31:21 2018
New Revision: 266460

URL: https://gcc.gnu.org/viewcvs?rev=266460&root=gcc&view=rev
Log:
2018-11-26  Richard Biener  

Backport from mainline
2018-10-15  Richard Biener  

PR middle-end/87610
* tree-ssa-structalias.c (struct vls_data): Add escaped_p member.
(visit_loadstore): When a used restrict tag escaped verify that
the points-to solution of "other" pointers do not include
escaped.
(compute_dependence_clique): If a used restrict tag escaped
communicated that down to visit_loadstore.

* gcc.dg/torture/restrict-6.c: New testcase.

2018-10-25  Richard Biener  

PR tree-optimization/87665
PR tree-optimization/87745
* tree-vectorizer.h (get_earlier_stmt): Remove.
(get_later_stmt): Pick up UID from the original non-pattern stmt.

* gfortran.dg/20181025-1.f: New testcase.

2018-10-24  Richard Biener  

PR tree-optimization/87665
* tree-vect-data-refs.c (vect_preserves_scalar_order_p): Adjust
to reflect reality.

* gcc.dg/torture/pr87665.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr87665.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/restrict-6.c
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/20181025-1.f
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-ssa-structalias.c
branches/gcc-7-branch/gcc/tree-vect-data-refs.c
branches/gcc-7-branch/gcc/tree-vectorizer.h

[Bug tree-optimization/87665] [7 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.3.1
 Resolution|--- |FIXED
  Known to fail||7.3.0

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

[Bug middle-end/87610] [7 Regression] wrong-code with restrict

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.3.1
 Resolution|--- |FIXED
  Known to fail||7.3.0

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

[Bug ada/88191] [9 Regression] ada bootstrap failure on alpha-linux-gnu ("SIGSYS" not declared in "Linux")

[charlet at gcc dot gnu.org]

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

Arnaud Charlet  changed:

   What|Removed |Added

 CC||charlet at gcc dot gnu.org

--- Comment #2 from Arnaud Charlet  ---
The patch for s-linux__alpha.ads is preapproved.
The Storage_Error is unrelated to this PR, so I'd suggest opening another one
after the patch is committed.

[Bug libstdc++/88199] [7/8/9 Regression] memory leak on unordered container move assignment

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |8.2.1
   Target Milestone|--- |7.4

[Bug c++/88181] [7/8/9 Regression] ICE: verify_type failed (error: type variant differs by TYPE_PACKED)

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
The C++ FE does

  if (flag_pack_struct)
{
  tree v;
  TYPE_PACKED (t) = 1;
  /* Even though the type is being defined for the first time
 here, there might have been a forward declaration, so there
 might be cv-qualified variants of T.  */
  for (v = TYPE_NEXT_VARIANT (t); v; v = TYPE_NEXT_VARIANT (v))
TYPE_PACKED (v) = 1;
}

Maybe starting with TYPE_MAIN_VARIANT will fix this (for no obvious reason)

[Bug ada/88191] [9 Regression] ada bootstrap failure on alpha-linux-gnu ("SIGSYS" not declared in "Linux")

[doko at debian dot org]

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

--- Comment #1 from Matthias Klose  ---
that fixes the build, taken from the sparc64 file.

--- gcc/ada/libgnarl/s-linux__alpha.ads (revision 266457)
+++ gcc/ada/libgnarl/s-linux__alpha.ads (working copy)
@@ -87,6 +87,7 @@
SIGKILL: constant := 9; --  kill (cannot be caught or ignored)
SIGBUS : constant := 10; --  bus error
SIGSEGV: constant := 11; --  segmentation violation
+   SIGSYS : constant := 12; --  bad system call
SIGPIPE: constant := 13; --  write on a pipe with no one to read it
SIGALRM: constant := 14; --  alarm clock
SIGTERM: constant := 15; --  software termination signal from kill


The build continues, but then fails with:

/home/packages/cross/9/p/gcc-cross-ports/gcc/build/./gcc/xgcc
-B/home/packages/cross/9/p/gcc-cross-ports/gcc/build/./gcc/ -
B/usr/alpha-linux-gnu/bin/ -B/usr/alpha-linux-gnu/lib/ -isystem
/usr/alpha-linux-gnu/include -isystem /usr/alpha-linux-gnu/
sys-include -isystem
/home/packages/cross/9/p/gcc-cross-ports/gcc/build/sys-include-c -g -O2  
-W -Wall -gnatpg -nostdi
nc  -gnatn  s-secsta.adb -o s-secsta.o

raised STORAGE_ERROR : stack overflow or erroneous memory access
make[8]: *** [../gcc-interface/Makefile:299: s-secsta.o] Error 1

[Bug c++/88181] [7/8/9 Regression] ICE: verify_type failed (error: type variant differs by TYPE_PACKED)

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Jan Hubicka from comment #4)
> It is possible that the verifier is just overzelaous here, but it seems it
> really does not make sense to have packed variant of nonpacked structure and
> vice versa because the memory layout is different. So i would say it is FE
> bug to create non-packed variant of packed type?

Yes.  Probably -fpack-struct is simply broken/bit-rotten.

[Bug lto/87988] [9 regression] Streaming of ABSTRACT_ORIGIN is expensive

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka  ---
> 
> Honza - can you test the effect of this patch please?
Thanks! I am just redoing the tests (rebuilding firefoxes with updated
tree), so i will do that today or tomorrow.

Honza

[Bug c++/88181] [7/8/9 Regression] ICE: verify_type failed (error: type variant differs by TYPE_PACKED)

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
It is possible that the verifier is just overzelaous here, but it seems it
really does not make sense to have packed variant of nonpacked structure and
vice versa because the memory layout is different. So i would say it is FE bug
to create non-packed variant of packed type?

[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"

[hjl.tools at gmail dot com]

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

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

[Bug target/86831] three failures in gfortran.fortran-torture with "-Ofast -march=native" on skylake-avx512

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #11 from H.J. Lu  ---
(In reply to janus from comment #10)
> Maybe it makes sense to add this (or the test case from PR 86735) to the
> testsuite? Although it is not caused by a bug in gcc itself, it would still
> be useful to detect if gcc is configured to use a problematic binutils
> version, I guess. (Note that only the skylake-avx512 architecture is
> affected.)

It is better to detect such binutils at configure time.

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

[Bug lto/87988] [9 regression] Streaming of ABSTRACT_ORIGIN is expensive

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Created attachment 45092
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45092&action=edit
better patch

This is a less hacky approach mimicking TREE_DIEs.  It elides BLOCK
BLOCK_ABSTRACT_ORIGIN if that is a BLOCK.  Downside is that the elided BLOCKs
are re-materialized for each _use_ as BLOCK_ABSTRACT_ORIGIN (that can probably
be fixed though with some extra overhead).  Also the overhead for streaming
is one NULL pointer in case BLOCK_ABSTRACT_ORIGIN is not set.

Honza - can you test the effect of this patch please?

I'll throw it on a LTO boostrap, it at least survives lto.exp testing ;)

[Bug c++/88181] [7/8/9 Regression] ICE: verify_type failed (error: type variant differs by TYPE_PACKED)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Target Milestone|--- |7.4
Summary|ICE: verify_type failed |[7/8/9 Regression] ICE:
   |(error: type variant|verify_type failed (error:
   |differs by TYPE_PACKED) |type variant differs by
   ||TYPE_PACKED)
 Ever confirmed|0   |1

[Bug target/88189] ix86_expand_sse_movcc and blend for scalars

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #2 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #1)
> So, the best chances to catch this would be in combine,

Ah, I thought it would be easier to generate blendv directly from
ix86_expand_sse_movcc, which already has almost everything needed, but indeed
recognizing the pattern (x & ~y) | (z & y) with y in {-1, 0} would apply in
even more cases.

[Bug libstdc++/88199] [7/8/9 Regression] memory leak on unordered container move assignment

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-26
   Assignee|unassigned at gcc dot gnu.org  |fdumont at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> Since allocator propagation was implemented in GCC 4.9,

i.e. since r198158

[Bug c++/88181] ICE: verify_type failed (error: type variant differs by TYPE_PACKED)

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #2)
> How could ICE start with a library change?

It was dependent to how Tuple class was defined. However doing a pre-processed
source file I see it starting from r223252, where the verification was added.

Reduced test-case:

$ cat x.ii
template < typename a > struct b { typedef a c; };
template < typename... > class d;
template < typename e > struct f {
  constexpr f(e) {}
};
template < int, typename... > struct g;
template < int h, typename e, typename... i >
struct g< h, e, i... > : g< 1, i... >, f< e > {
  constexpr g(e j, i... k) : g< 1, i... >(k...), f< e >(j) {}
};
template < int h, typename e > struct g< h, e > : f< e > {
  constexpr g(e j) : f< e >(j) {}
};
template < typename l, typename m > class d< l, m > : g< 0, l, m > {
public:
  constexpr d(l n, m o) : g< 0, l, m >(n, o) {}
  void operator=(typename b< const d >::c);
};
struct p {};
struct t {};
int main() {
  p q;
  t r;
  constexpr d< p, t > s(q, r);
}