[Bug tree-optimization/85478] ICE with single element vector

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/85839] [F2018] warn for obsolescent features

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
Author: janus
Date: Fri May 25 06:09:10 2018
New Revision: 260705

URL: https://gcc.gnu.org/viewcvs?rev=260705&root=gcc&view=rev
Log:
2018-05-25  Janus Weil  

PR fortran/85839
* match.c (gfc_match_block_data): Call gfc_notify_std to warn about
an obsolescent feature in Fortran 2018.
(gfc_match_equivalence): Ditto.
* resolve.c (resolve_common_blocks): Ditto.
(gfc_resolve_forall): Ditto.
* symbol.c (gfc_define_st_label): Ditto.


2018-05-25  Janus Weil  

PR fortran/85839
* gfortran.dg/f2018_obs.f90: New test case.

Added:
trunk/gcc/testsuite/gfortran.dg/f2018_obs.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog

[Bug target/85900] [9 Regression] ICEs after revision r260547 on darwin.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-25
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Revision r260683 fixes the ICE for the test gcc.dg/torture/pr48044.c, but not
for the second one in comment 0:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x4)
frame #0: 0x00010121f078 cc1`assemble_alias(tree_node*, tree_node*) at
varasm.c:5921
   5918   if (!DECL_WEAK (decl))
   5919 {
   5920   if (TREE_CODE (decl) == FUNCTION_DECL
-> 5921   && cgraph_node::get (decl)->ifunc_resolver)
   5922 error_at (DECL_SOURCE_LOCATION (decl),
   5923   "ifunc is not supported in this configuration");
   5924   else
Target 0: (cc1) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x4)
  * frame #0: 0x00010121f078 cc1`assemble_alias(tree_node*, tree_node*) at
varasm.c:5921
frame #1: 0x000100abe828
cc1`rest_of_decl_compilation(decl=0x000145957200, top_level=,
at_end=0) at passes.c:193
frame #2: 0x00010001b3cf cc1`finish_decl(decl=0x000145957200,
init_loc=, init=, origtype=,
asmspec_tree=) at c-decl.c:5120
frame #3: 0x000100077688
cc1`::c_parser_declaration_or_fndef(parser=0x00014580f168,
fndef_ok=, static_assert_ok=, empty_ok=,
nested=, start_attr_ok=,
objc_foreach_object_declaration=,
omp_declare_simd_clauses=vec @ 0x7ffeefbff008,
oacc_routine_data=, fallthru_attr_p=) at
c-parser.c:2175
frame #4: 0x00010007f54e
cc1`::c_parser_external_declaration(parser=0x00014580f168) at
c-parser.c:1643
frame #5: 0x00010007fde4 cc1`c_parse_file() at c-parser.c:1524
frame #6: 0x0001000d393e cc1`c_common_parse_file() at c-opts.c:1132
frame #7: 0x000100bbacda cc1`::compile_file() at toplev.c:455
frame #8: 0x0001012348ab cc1`toplev::main(int, char**) at toplev.c:2132
frame #9: 0x0001012363ee cc1`main(argc=2, argv=0x7ffeefbff250) at
main.c:39

[Bug web/85917] New: GCC 8 Changes page fails to mention change of default mode for C

[Arfrever.FTA at GMail dot Com]

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

Bug ID: 85917
   Summary: GCC 8 Changes page fails to mention change of default
mode for C
   Product: gcc
   Version: 8.1.0
   URL: https://gcc.gnu.org/gcc-8/changes.html
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Arfrever.FTA at GMail dot Com
  Target Milestone: ---

GCC 8 changed default mode for C from -std=gnu11 to -std=gnu17, but
https://gcc.gnu.org/gcc-8/changes.html does not mention this change.


$ diff -u <(gcc-7.3.0 -E -dM -x c - < /dev/null | sort) <(gcc-8.1.0 -E -dM -x c
- < /dev/null | sort) | grep -C2 __STDC_VERSION__
 #define __STDC_UTF_16__ 1
 #define __STDC_UTF_32__ 1
-#define __STDC_VERSION__ 201112L
+#define __STDC_VERSION__ 201710L
 #define __STDC__ 1
 #define __UINT16_C(c) c


For comparison, https://gcc.gnu.org/gcc-5/changes.html contains:
"""
Caveats
The default mode for C is now -std=gnu11 instead of -std=gnu89.
...
New Languages and Language specific improvements
...
  C
The default mode has been changed to -std=gnu11.
"""

[Bug web/85916] New: GCC 8 Changes page has outdated mention of -mibt, -mcet and maybe -mshstk

[Arfrever.FTA at GMail dot Com]

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

Bug ID: 85916
   Summary: GCC 8 Changes page has outdated mention of -mibt,
-mcet and maybe -mshstk
   Product: gcc
   Version: 8.1.0
   URL: https://gcc.gnu.org/gcc-8/changes.html
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Arfrever.FTA at GMail dot Com
CC: hjl.tools at gmail dot com
  Target Milestone: ---

https://gcc.gnu.org/gcc-8/changes.html contains:
  In "General Improvements" section:
  A new option -fcf-protection=[full|branch|return|none] is introduced to
perform code instrumentation to increase program security by checking that
target addresses of control-flow transfer instructions (such as indirect
function call, function return, indirect jump) are valid. Currently the
instrumentation is supported on x86 GNU/Linux targets only. See the user guide
for further information about the option syntax and section "New Targets and
Target Specific Improvements" for IA-32/x86-64 for more details.


  In "New Targets and Target Specific Improvements" section:
In "IA-32/x86-64" subsection:
  GCC now supports the Intel Control-flow Enforcement Technology (CET)
extension through -mibt, -mshstk, -mcet options. One of these options has to
accompany the -fcf-protection option to enable code instrumentation for
control-flow protection.


-mibt option was deleted (bug #85469).
-mcet option was deleted (bug #85485).
-mshstk option probably has slightly changed meaning.

[Bug target/85915] New: -mfunction-return=thunk causes multiple definition of `__x86_return_thunk'

[Arfrever.FTA at GMail dot Com]

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

Bug ID: 85915
   Summary: -mfunction-return=thunk causes multiple definition of
`__x86_return_thunk'
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Arfrever.FTA at GMail dot Com
CC: hjl.tools at gmail dot com
  Target Milestone: ---

This is a regression in GCC 8.1.0.


$ gcc-7.3.0 -mfunction-return=thunk -o test -x c - <<< 'int main(){}'
$ gcc-8.1.0 -mfunction-return=thunk -o test -x c - <<< 'int main(){}'
/usr/lib64/libc_nonshared.a(elf-init.oS): In function `__x86_return_thunk':
(.text.__x86_indirect_thunk[__x86_indirect_thunk]+0x0): multiple definition of
`__x86_return_thunk'
/tmp/ccPGIDNm.o::(.text.__x86_return_thunk[__x86_return_thunk]+0x0): first
defined here
collect2: error: ld returned 1 exit status


I use glibc-2.27, binutils-2.30.
Most of my system (including glibc) was compiled with GCC 7.3.0 with CFLAGS /
CXXFLAGS including -mfunction-return=thunk -mindirect-branch=thunk
-mindirect-branch-register.
I suspect that this bug might be reproducible only when glibc was compiled with
-mfunction-return=thunk.

[Bug target/85666] gcc-8.0.1 fails to build mmix target: gcc/libgcc/libgcc2.h:203:20: internal compiler error: in leaf_function_p, at final.c:4488

[hp at gcc dot gnu.org]

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

--- Comment #10 from Hans-Peter Nilsson  ---
Created attachment 44180
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44180&action=edit
patch to mmix.c

Builds libgcc.  More late this weekend, I hope.

[Bug target/85666] gcc-8.0.1 fails to build mmix target: gcc/libgcc/libgcc2.h:203:20: internal compiler error: in leaf_function_p, at final.c:4488

[hp at gcc dot gnu.org]

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

--- Comment #9 from Hans-Peter Nilsson  ---
(In reply to Wilco from comment #8)
> I don't think that comment is accurate.

Of course it isn't accurate *now*, but it explains why the code looks as it is.
I see the "phase-computing" code in expand_used_vars was added in 2004, but the
port is from 2001.

> The failure happens in cfgexpand
> before any RTL has been generated, so leaf_function_p must not be called
> this early. If starting_frame_offset doesn't remain constant things can go
> badly wrong.

Correct.

> The easiest fix is to always allocate an extra stack slot with exceptions
> and then avoid generating extra code in the prolog/epilog if it happens to
> be a leaf function.

Easiest perhaps, but far from right.  Don't worry about it.

It's just a pity leaf_function_p is so useless, but there are other ways.

[Bug fortran/85543] ICE in update_current_proc_array_outer_dependency, at fortran/resolve.c:3060

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri May 25 00:39:23 2018
New Revision: 260704

URL: https://gcc.gnu.org/viewcvs?rev=260704&root=gcc&view=rev
Log:
2018-05-24  Steven G. Kargl  

PR fortran/85543
* resolve.c (update_current_proc_array_outer_dependency): Avoid NULL
pointer dereference.


2018-05-24  Steven G. Kargl  

PR fortran/85543
* gfortran.dg/pr85543.f90: New test.

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

[Bug fortran/85543] ICE in update_current_proc_array_outer_dependency, at fortran/resolve.c:3060

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

[Bug fortran/85780] ICE in resolve_fl_procedure, at fortran/resolve.c:12504

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu May 24 23:28:35 2018
New Revision: 260698

URL: https://gcc.gnu.org/viewcvs?rev=260698&root=gcc&view=rev
Log:
2018-05-24  Steven G. Kargl  

PR fortran/85780
* resolve.c (resolve_fl_procedure): Avoid NULL dereference.

2018-05-24  Steven G. Kargl  

PR fortran/85780
* gfortran.dg/pr85780.f90: New test.

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

[Bug c++/85914] New: -Wreturn-type false positive with tautological ternery

[Anderson.Ku at synopsys dot com]

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

Bug ID: 85914
   Summary: -Wreturn-type false positive with tautological ternery
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Anderson.Ku at synopsys dot com
  Target Milestone: ---

$uname -a
Linux anku-Z440 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018
x86_64 x86_64 x86_64 GNU/Linux

$g++ --version
g++ (GCC) 7.1.0

$g++ /u/anku/test.cpp -c -Wreturn-type
/u/anku/test.cpp: In function 'int processDMInitActivity(int)':
/u/anku/test.cpp:16:1: warning: control reaches end of non-void function
[-Wreturn-type]
 }
 ^

Adding -O1, -O2, or O3 removes the warning

isolated code:

__attribute__((noreturn)) void throw_assert();

struct MyClassWithVirtualDtor{
virtual ~MyClassWithVirtualDtor();
};

int processDMInitActivity(int x) {
MyClassWithVirtualDtor mcf;
if(x) {
return -1;
}
false ? void(0) : throw_assert();

// This also warns
// false ? void(0) : throw 303;
}

[Bug testsuite/85913] New: [9 Regression] FAIL: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower1 "Removing basic block"

[hjl.tools at gmail dot com]

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

Bug ID: 85913
   Summary: [9 Regression] FAIL: gcc.dg/tree-prof/update-loopch.c
scan-tree-dump switchlower1 "Removing basic block"
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: mliska at suse dot cz
  Target Milestone: ---

On x86-64, r260350 caused:

FAIL: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower1 "Removing
basic block"

There is no change in generated assembly code.  But basic blocks are removed
in different passes now.

[Bug fortran/85779] ICE in gfc_typename, at fortran/misc.c:156

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu May 24 22:31:11 2018
New Revision: 260697

URL: https://gcc.gnu.org/viewcvs?rev=260697&root=gcc&view=rev
Log:
2018-05-24  Steven G. Kargl  

PR fortran/85779
* decl.c (gfc_match_derived_decl): Fix NULL point dereference.

2018-05-24  Steven G. Kargl  

PR fortran/85779
* gfortran.dg/pr85779_1.f90: New test.
* gfortran.dg/pr85779_2.f90: Ditto.
* gfortran.dg/pr85779_3.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/pr85779_1.f90
trunk/gcc/testsuite/gfortran.dg/pr85779_2.f90
trunk/gcc/testsuite/gfortran.dg/pr85779_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/85895] [6/7/8/9 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3518

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu May 24 22:28:33 2018
New Revision: 260696

URL: https://gcc.gnu.org/viewcvs?rev=260696&root=gcc&view=rev
Log:
2018-05-24  Steven G. Kargl  

PR fortran/85895
* resolve.c (resolve_sync): Resolve expression before checking for
an error.

2018-05-24  Steven G. Kargl  

PR fortran/85895

* gfortran.dg/coarray_3.f90: Fix invalid testcase.
* gfortran.dg/pr85895.f90: New test.

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

[Bug c++/85912] New: -fdump-lang-raw ICE on valid code

[romain.geissler at amadeus dot com]

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

Bug ID: 85912
   Summary: -fdump-lang-raw ICE on valid code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

This simple snippet, when built with -fdump-lang-raw will ICE:

cat test.cpp
void f()
{   
switch(1)
{
case 1:
break;
}
}

int i;


/opt/1A/toolchain/x86_64-2.6.32-v4/bin/g++ -fdump-lang-raw -c test.cpp
test.cpp:10:6: internal compiler error: Segmentation fault
 int i;
  ^ 
0xd88197 ???
/workdir/src/gcc-8.1.1/gcc/toplev.c:325
0xd790dd ???
/workdir/src/gcc-8.1.1/gcc/tree.c:12677
0x6631aa ???
/workdir/src/gcc-8.1.1/gcc/cp/decl2.c:4566
0x1075d15 ???
/workdir/src/gcc-8.1.1/gcc/cp/decl2.c:5007
0xfc21e3 ???
/workdir/src/gcc-8.1.1/gcc/toplev.c:455
0xf20969 ???
/workdir/src/gcc-8.1.1/gcc/toplev.c:2132
0xf1f2ba ???
/workdir/src/gcc-8.1.1/gcc/main.c:39

while it works perfectly fine without -fdump-lang-raw.

/opt/1A/toolchain/x86_64-2.6.32-v4/bin/g++ --version
g++ (GCC) 8.1.1 20180523
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Cheers,
Romain

[Bug c/66970] Add __has_builtin() macro

[hpa at zytor dot com]

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

H. Peter Anvin  changed:

   What|Removed |Added

 CC||hpa at zytor dot com

--- Comment #9 from H. Peter Anvin  ---
Can I please second this request? This would be extremely useful in the Linux
kernel, *and* it would be extremely useful in any code that for whatever reason
cannot depend on any particular build system.

[Bug testsuite/85911] [9 regression] gcc.dg/tree-prof/update-loopch.c fails starting with r260638

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug testsuite/85911] [9 regression] gcc.dg/tree-prof/update-loopch.c fails starting with r260638

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-24
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Rainer Orth  ---
As I've mentioned several times in this thread

https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01342.html

the scan-tree-dump* tests were UNSUPPORTED before my patch because they hadn't
been updated to look for the changed dumpfile name.  Now that this is fixed,
the new FAIL is exposed.

[Bug testsuite/85911] New: [9 regression] gcc.dg/tree-prof/update-loopch.c fails starting with r260638

[seurer at gcc dot gnu.org]

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

Bug ID: 85911
   Summary: [9 regression] gcc.dg/tree-prof/update-loopch.c fails
starting with r260638
   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: ---

Looks like the the one variation doesn't work in the test case update:

# of expected passes8
# of unexpected failures1
# of unsupported tests  1
FAIL: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower1 "Removing
basic block"



PASS: gcc.dg/tree-prof/update-loopch.c execution,-fprofile-use
-D_PROFILE_USE
PASS: gcc.dg/tree-prof/update-loopch.c scan-ipa-dump profile "loop depth 1,
count 4"
PASS: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower1 "loop depth
1, count 3"
PASS: gcc.dg/tree-prof/update-loopch.c scan-tree-dump-not switchlower1 "loop
depth 1, count 2"
FAIL: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower1 "Removing
basic block"
PASS: gcc.dg/tree-prof/update-loopch.c scan-tree-dump-not switchlower1 "Invalid
sum"


r260638 | ro | 2018-05-24 07:27:01 -0500 (Thu, 24 May 2018) | 4 lines

Fix dumpfile name in gcc.dg/tree-prof/update-loopch.c

* gcc.dg/tree-prof/update-loopch.c: Fix dumpfile name in
scan-tree-dump*.

[Bug target/85903] [9 Regression] FAIL: gcc.target/i386/avx512dq-vcvtuqq2pd-2.c

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu May 24 21:25:49 2018
New Revision: 260692

URL: https://gcc.gnu.org/viewcvs?rev=260692&root=gcc&view=rev
Log:
PR target/85903
* config/i386/sse.md (movdi_to_sse): Do not generate pseudo
when memory input operand is handled.


Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/sse.md

[Bug bootstrap/85850] [9 Regression] gcc 9.0 doesn't compile with Xcode 9.3.1

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Gallager  ---
(In reply to Jürgen Reuter from comment #6)
> This was indeed introduced in r260343 and was fixed in r260620. I tried out
> r260633 today, and it compiles and bootstraps again without any problem. So
> I think this can be closed.

OK.

[Bug tree-optimization/85478] ICE with single element vector

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #11 from Jeffrey A. Law  ---
So is this BZ fixed on Andreas?  If so, let's close it.  I'll also take your
patch out of my queue of things to review :-)

[Bug sanitizer/85835] libsanitizer includes unconditionally

[hjl at gcc dot gnu.org]

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

--- Comment #7 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu May 24 20:21:54 2018
New Revision: 260688

URL: https://gcc.gnu.org/viewcvs?rev=260688&root=gcc&view=rev
Log:
libsanitizer: Use pre-computed size of struct ustat for Linux

Cherry-pick compiler-rt revision 333213:

 has been removed from glibc 2.28 by:

commit cf2478d53ad7071e84c724a986b56fe17f4f4ca7
Author: Adhemerval Zanella 
Date:   Sun Mar 18 11:28:59 2018 +0800

Deprecate ustat syscall interface

This patch uses pre-computed size of struct ustat for Linux.

PR sanitizer/85835
* sanitizer_common/sanitizer_platform_limits_posix.cc: Don't
include  for Linux.
(SIZEOF_STRUCT_USTAT): New.
(struct_ustat_sz): Use SIZEOF_STRUCT_USTAT for Linux.


Modified:
branches/gcc-7-branch/libsanitizer/ChangeLog
   
branches/gcc-7-branch/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc

[Bug sanitizer/85835] libsanitizer includes unconditionally

[hjl at gcc dot gnu.org]

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

--- Comment #6 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu May 24 20:07:25 2018
New Revision: 260687

URL: https://gcc.gnu.org/viewcvs?rev=260687&root=gcc&view=rev
Log:
libsanitizer: Use pre-computed size of struct ustat for Linux

Cherry-pick compiler-rt revision 333213:

 has been removed from glibc 2.28 by:

commit cf2478d53ad7071e84c724a986b56fe17f4f4ca7
Author: Adhemerval Zanella 
Date:   Sun Mar 18 11:28:59 2018 +0800

Deprecate ustat syscall interface

This patch uses pre-computed size of struct ustat for Linux.

PR sanitizer/85835
* sanitizer_common/sanitizer_platform_limits_posix.cc: Don't
include  for Linux.
(SIZEOF_STRUCT_USTAT): New.
(struct_ustat_sz): Use SIZEOF_STRUCT_USTAT for Linux.

Modified:
branches/gcc-8-branch/libsanitizer/ChangeLog
   
branches/gcc-8-branch/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc

[Bug c++/85842] [8/9 Regression] Bogus -Wreturn-type with generic lambda and constexpr if

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Thu May 24 20:03:56 2018
New Revision: 260686

URL: https://gcc.gnu.org/viewcvs?rev=260686&root=gcc&view=rev
Log:
PR c++/85842 - -Wreturn-type, constexpr if and generic lambda.

* pt.c (tsubst_lambda_expr): Copy current_function_returns_* to
generic lambda.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/constexpr-if23.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/pt.c

[Bug c++/85842] [8/9 Regression] Bogus -Wreturn-type with generic lambda and constexpr if

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu May 24 20:03:18 2018
New Revision: 260685

URL: https://gcc.gnu.org/viewcvs?rev=260685&root=gcc&view=rev
Log:
PR c++/85842 - -Wreturn-type, constexpr if and generic lambda.

* pt.c (tsubst_lambda_expr): Copy current_function_returns_* to
generic lambda.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if23.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug sanitizer/85835] libsanitizer includes unconditionally

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #5 from H.J. Lu  ---
Fixed.

[Bug sanitizer/85835] libsanitizer includes unconditionally

[hjl at gcc dot gnu.org]

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

--- Comment #4 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu May 24 19:52:32 2018
New Revision: 260684

URL: https://gcc.gnu.org/viewcvs?rev=260684&root=gcc&view=rev
Log:
libsanitizer: Use pre-computed size of struct ustat for Linux

Cherry-pick compiler-rt revision 333213:

 has been removed from glibc 2.28 by:

commit cf2478d53ad7071e84c724a986b56fe17f4f4ca7
Author: Adhemerval Zanella 
Date:   Sun Mar 18 11:28:59 2018 +0800

Deprecate ustat syscall interface

This patch uses pre-computed size of struct ustat for Linux.

PR sanitizer/85835
* sanitizer_common/sanitizer_platform_limits_posix.cc: Don't
include  for Linux.
(SIZEOF_STRUCT_USTAT): New.
(struct_ustat_sz): Use SIZEOF_STRUCT_USTAT for Linux.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc

[Bug target/85900] [9 Regression] ICEs after revision r260547 on darwin.

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu May 24 19:51:09 2018
New Revision: 260683

URL: https://gcc.gnu.org/viewcvs?rev=260683&root=gcc&view=rev
Log:
Check ifunc_resolver only on FUNCTION_DECL

Since ifunc_resolver is only valid on FUNCTION_DECL, check ifunc_resolver
only on FUNCTION_DECL.

PR target/85900
PR target/85345
* varasm.c (assemble_alias): Check ifunc_resolver only on
FUNCTION_DECL.

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

[Bug target/85345] Missing ENDBR in IFUNC resolver

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu May 24 19:51:09 2018
New Revision: 260683

URL: https://gcc.gnu.org/viewcvs?rev=260683&root=gcc&view=rev
Log:
Check ifunc_resolver only on FUNCTION_DECL

Since ifunc_resolver is only valid on FUNCTION_DECL, check ifunc_resolver
only on FUNCTION_DECL.

PR target/85900
PR target/85345
* varasm.c (assemble_alias): Check ifunc_resolver only on
FUNCTION_DECL.

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

[Bug target/85894] PPC64LE alloca stack slot allocation allows memset to destroy the stack

[rcardoso at linux dot vnet.ibm.com]

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

--- Comment #4 from Rogerio Alves  ---
(In reply to Tulio Magno Quites Machado Filho from comment #2)

> This is loading 0 because of glibc bug #21895, where the TOC pointer is not
> restored in the stack frame for static programs.
> That's why the the segfault happens.

Yes it's happening because TOC pointer is not being restored. In fact I already
sent a patch to libc that fix this. But, I was not sure about this behavior on
alloca.

[Bug target/85894] PPC64LE alloca stack slot allocation allows memset to destroy the stack

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #3 from seurer at gcc dot gnu.org ---
The link in Tulio's comment came out wrong.  The correct link to the glibc
bugzilla is:  https://sourceware.org/bugzilla/show_bug.cgi?id=21895

[Bug target/85910] New: config/aarch64/aarch64.c:15653:12: warning: duplicated ‘if’ condition

[dcb314 at hotmail dot com]

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

Bug ID: 85910
   Summary: config/aarch64/aarch64.c:15653:12: warning: duplicated
‘if’ condition
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

svn blame says:

256612   rsandifo   if (d->vec_flags == VEC_SVE_DATA)
256612   rsandifo   return aarch64_evpc_sve_tbl (d);
256612   rsandifo   else if (d->vec_flags == VEC_SVE_DATA)
256612   rsandifo   return aarch64_evpc_tbl (d);

Possible typo ?

[Bug target/85909] New: [MIPS] Inconsistent operand constraints error with complex double inline asm operands and o32 ABI

[ma...@linux-mips.org]

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

Bug ID: 85909
   Summary: [MIPS] Inconsistent operand constraints error with
complex double inline asm operands and o32 ABI
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ma...@linux-mips.org
  Target Milestone: ---
Target: mips*-*-*

Created attachment 44179
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44179&action=edit
Source to reproduce the problem

The program attached (a GDB test case) fails to build with the o32 ABI
(`-mips32r2 -mfp64'; fiddle with _MIPS_FPSET #ifdef to reproduce with
`-mfp32' too) reporting:

mips-fpregset-core.c: In function 'main':
mips-fpregset-core.c:66:3: error: inconsistent operand constraints in an 'asm'
   asm (
   ^~~

It builds just fine with the n32 and n64 ABIs and produces correct code.

[Bug bootstrap/85850] [9 Regression] gcc 9.0 doesn't compile with Xcode 9.3.1

[juergen.reuter at desy dot de]

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

--- Comment #6 from Jürgen Reuter  ---
This was indeed introduced in r260343 and was fixed in r260620. I tried out
r260633 today, and it compiles and bootstraps again without any problem. So I
think this can be closed.

[Bug fortran/85779] ICE in gfc_typename, at fortran/misc.c:156

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

[Bug fortran/85780] ICE in resolve_fl_procedure, at fortran/resolve.c:12504

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

[Bug target/85903] [9 Regression] FAIL: gcc.target/i386/avx512dq-vcvtuqq2pd-2.c

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu May 24 18:16:29 2018
New Revision: 260681

URL: https://gcc.gnu.org/viewcvs?rev=260681&root=gcc&view=rev
Log:
PR target/85903
* config/i386/sse.md (movdi_to_sse): Do not generate pseudo
when memory input operand is handled.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md

[Bug libfortran/85906] Conditional jump depends on uninitialized value in write_decimal / write_integer

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jvdelisle at gcc dot gnu.org,
   ||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
I've added Jerry to the CC as he's probably the most familiar with
this area of the library.  Jerry, does this one-line patch look
correct or are there deeper issues to look into?

[Bug target/85904] [7/8/9 Regression] configure issue cross compiling on netbsd, with patch

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu May 24 17:31:13 2018
New Revision: 260678

URL: https://gcc.gnu.org/viewcvs?rev=260678&root=gcc&view=rev
Log:
PR target/85904 check for aligned_alloc on netbsd cross-compilation

2018-05-24  Maya Rashish  

PR target/85904
* crossconfig.m4: Test for aligned_alloc on netbsd.
* configure: Regenerate.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/crossconfig.m4

[Bug c++/85807] [8/9 Regression] ICEs related to noexcept

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/85908] New: Internal error with concepts and polymorphic lambdas

[josedaniel.garcia at uc3m dot es]

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

Bug ID: 85908
   Summary: Internal error with concepts and polymorphic lambdas
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: josedaniel.garcia at uc3m dot es
  Target Milestone: ---

Using a polymorphic lambda with a concept causes an internal error. 

I have tried with g++7 and g++8 when compiling with -fconcepts

Source code

#include 
#include 
#include 

template 
struct value_type {
  using type = typename T::value_type;
};

template 
struct value_type {
  using type = T;
};

template 
struct value_type {
  using type = T;
};

template 
using value_type_t = typename value_type>::type;

template 
struct iterator_type {
  using type = typename T::iterator;
};

template 
using iterator_type_t =
typename iterator_type>::type;

template 
concept bool Range =
  requires(R r) {
typename iterator_type_t;
{ r.begin() } -> iterator_type_t;
  };

template 
concept bool Combiner = Range &&
  requires(value_type_t x, value_type_t y, C && c)  {
{ c(x,y) } -> value_type_t;
};

//template  C>
template 
  requires Combiner
auto reduce(const R & r, C && c) {
  auto it = r.begin();
  auto s = *it;
  while (it++ != r.end()) { s = c(s,*it); }
  return s;
};

int main() {
  std::vector v{1,2,3};
  std::cout << "r=" << reduce(v,[](auto x, int y) { return x+y; });
  return 0;
}

Compiler output:

: In instantiation of 'main():: [with auto:1 =
int]':

:42:8:   required from here

:57:65: internal compiler error: Segmentation fault

   std::cout << "r=" << reduce(v,[](auto x, int y) { return x+y; });

 ^

mmap: Cannot allocate memory

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

Compiler returned: 1

[Bug target/85904] [7/8/9 Regression] configure issue cross compiling on netbsd, with patch

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Patch posted: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01366.html

[Bug libstdc++/85886] std::atomic<> doesn't have value_type and difference_type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
The new typedefs have been added unconditionally (not just for C++17).

[Bug libstdc++/69769] arithmetic operation on pointer to a function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
The C++17 standard says that arithmetic on atomic pointer types is ill-formed,
so libstdc++ now enforces that for C++17 and later.

[Bug libstdc++/85886] std::atomic<> doesn't have value_type and difference_type

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu May 24 15:28:26 2018
New Revision: 260676

URL: https://gcc.gnu.org/viewcvs?rev=260676&root=gcc&view=rev
Log:
Implement P0558R2 changes to std::atomic

The restrictions forbidding arithmetic on atomic pointer types are only
enabled for C++17 and later, retaining the GNU extension for older
standards. The new nested typedefs and changes to prevent scalar
parameters participating in template argument deduction are enabled
unconditionally.

PR libstdc++/69769
PR libstdc++/85886
* include/bits/atomic_base.h (__atomic_base::value_type)
(__atomic_base::difference_type): Add new typedefs.
* include/std/atomic (atomic::value_type, atomic::value_type)
(atomic::value_type, atomic::difference_type): Likewise.
(atomic::operator++, atomic::operator--)
(atomic::operator+=, atomic::operator-=)
(atomic::fetch_add, atomic::fetch_sub): Add static assertion
to enforce C++17 requirement on pointer arithmetic.
(__atomic_val_t, __atomic_diff_t): New alias templates.
(atomic_init, atomic_store_explicit, atomic_exchange_explicit)
(atomic_compare_exchange_weak_explicit)
(atomic_compare_exchange_strong_explicit, atomic_store)
(atomic_exchange, atomic_compare_exchange_weak)
(atomic_compare_exchange_strong): Use __atomic_val_t to make
scalar parameters be non-deduced contexts.
(atomic_fetch_add_explicit, atomic_fetch_sub_explicit)
(atomic_fetch_add, atomic_fetch_sub): Change first parameter to be
atomic instead of __atomic_base, and use __atomic_diff_t for scalar
parameters.
(atomic_fetch_and_explicit, atomic_fetch_or_explicit)
(atomic_fetch_xor_explicit, atomic_fetch_and, atomic_fetch_or)
(atomic_fetch_xor): Use __atomic_val_t for scalar parameters.
(atomic_fetch_add_explicit, atomic_fetch_sub_explicit)
(atomic_fetch_add, atomic_fetch_sub): Remove overloads for atomic
address types.
* testsuite/29_atomics/atomic/60695.cc: Adjust dg-error lineno.
* testsuite/29_atomics/atomic/69769.cc: New test.
* testsuite/29_atomics/atomic/nonmembers.cc: New test.
* testsuite/29_atomics/atomic/operators/pointer_partial_void.cc:
Disable test for C++17 and later.
* testsuite/29_atomics/atomic/requirements/typedefs.cc: New test.
* testsuite/29_atomics/atomic_integral/nonmembers.cc: New test.
* testsuite/29_atomics/atomic_integral/requirements/typedefs.cc: New
test.

Added:
trunk/libstdc++-v3/testsuite/29_atomics/atomic/69769.cc
trunk/libstdc++-v3/testsuite/29_atomics/atomic/nonmembers.cc
trunk/libstdc++-v3/testsuite/29_atomics/atomic/requirements/typedefs.cc
  - copied, changed from r260635,
trunk/libstdc++-v3/testsuite/29_atomics/atomic/60695.cc
trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/nonmembers.cc
   
trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/requirements/typedefs.cc
  - copied, changed from r260635,
trunk/libstdc++-v3/testsuite/29_atomics/atomic/60695.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/atomic_base.h
trunk/libstdc++-v3/include/std/atomic
trunk/libstdc++-v3/testsuite/29_atomics/atomic/60695.cc
   
trunk/libstdc++-v3/testsuite/29_atomics/atomic/operators/pointer_partial_void.cc

[Bug libstdc++/69769] arithmetic operation on pointer to a function

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Thu May 24 15:28:26 2018
New Revision: 260676

URL: https://gcc.gnu.org/viewcvs?rev=260676&root=gcc&view=rev
Log:
Implement P0558R2 changes to std::atomic

The restrictions forbidding arithmetic on atomic pointer types are only
enabled for C++17 and later, retaining the GNU extension for older
standards. The new nested typedefs and changes to prevent scalar
parameters participating in template argument deduction are enabled
unconditionally.

PR libstdc++/69769
PR libstdc++/85886
* include/bits/atomic_base.h (__atomic_base::value_type)
(__atomic_base::difference_type): Add new typedefs.
* include/std/atomic (atomic::value_type, atomic::value_type)
(atomic::value_type, atomic::difference_type): Likewise.
(atomic::operator++, atomic::operator--)
(atomic::operator+=, atomic::operator-=)
(atomic::fetch_add, atomic::fetch_sub): Add static assertion
to enforce C++17 requirement on pointer arithmetic.
(__atomic_val_t, __atomic_diff_t): New alias templates.
(atomic_init, atomic_store_explicit, atomic_exchange_explicit)
(atomic_compare_exchange_weak_explicit)
(atomic_compare_exchange_strong_explicit, atomic_store)
(atomic_exchange, atomic_compare_exchange_weak)
(atomic_compare_exchange_strong): Use __atomic_val_t to make
scalar parameters be non-deduced contexts.
(atomic_fetch_add_explicit, atomic_fetch_sub_explicit)
(atomic_fetch_add, atomic_fetch_sub): Change first parameter to be
atomic instead of __atomic_base, and use __atomic_diff_t for scalar
parameters.
(atomic_fetch_and_explicit, atomic_fetch_or_explicit)
(atomic_fetch_xor_explicit, atomic_fetch_and, atomic_fetch_or)
(atomic_fetch_xor): Use __atomic_val_t for scalar parameters.
(atomic_fetch_add_explicit, atomic_fetch_sub_explicit)
(atomic_fetch_add, atomic_fetch_sub): Remove overloads for atomic
address types.
* testsuite/29_atomics/atomic/60695.cc: Adjust dg-error lineno.
* testsuite/29_atomics/atomic/69769.cc: New test.
* testsuite/29_atomics/atomic/nonmembers.cc: New test.
* testsuite/29_atomics/atomic/operators/pointer_partial_void.cc:
Disable test for C++17 and later.
* testsuite/29_atomics/atomic/requirements/typedefs.cc: New test.
* testsuite/29_atomics/atomic_integral/nonmembers.cc: New test.
* testsuite/29_atomics/atomic_integral/requirements/typedefs.cc: New
test.

Added:
trunk/libstdc++-v3/testsuite/29_atomics/atomic/69769.cc
trunk/libstdc++-v3/testsuite/29_atomics/atomic/nonmembers.cc
trunk/libstdc++-v3/testsuite/29_atomics/atomic/requirements/typedefs.cc
  - copied, changed from r260635,
trunk/libstdc++-v3/testsuite/29_atomics/atomic/60695.cc
trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/nonmembers.cc
   
trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/requirements/typedefs.cc
  - copied, changed from r260635,
trunk/libstdc++-v3/testsuite/29_atomics/atomic/60695.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/atomic_base.h
trunk/libstdc++-v3/include/std/atomic
trunk/libstdc++-v3/testsuite/29_atomics/atomic/60695.cc
   
trunk/libstdc++-v3/testsuite/29_atomics/atomic/operators/pointer_partial_void.cc

[Bug target/85904] [7/8/9 Regression] configure issue cross compiling on netbsd, with patch

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||6.4.0
Summary|configure issue cross   |[7/8/9 Regression]
   |compiling on netbsd, with   |configure issue cross
   |patch   |compiling on netbsd, with
   ||patch
  Known to fail||7.3.0, 8.1.0, 9.0

--- Comment #2 from Jonathan Wakely  ---
I'm marking this as a regression in gcc 7 and later, because r240056 (which
added the aligned_alloc configure check for native compilers) first appeared in
gcc-7

[Bug c++/85815] [7/8/9 Regression] incorrect "invalid use of incomplete type" in a lambda on valid code

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug testsuite/63177] Powerpc no-vfa-vect-depend-2.c and no-vfa-vect-depend-3.c failures

[carll at gcc dot gnu.org]

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

Carl Love  changed:

   What|Removed |Added

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

--- Comment #7 from Carl Love  ---
So the bug only occurs if GCC is configured wfor power8 or you also use the
option -mcpu=power8 when compiling the test.  If you configure with or use
-mcpu-power9 then the proper code generation is done.  

Pat Haugen looked at this issue.  It appears that GCC is calling the assembler
with -mpower9 causing the P9 "stxvx" instruction to be generated to store the
data in the correct order.  In the case of power8 the compiler passes -mpower8
to the assembler which uses the "stxvx" extended mnemonic which maps to stxvd2x
which doesn't store the data in the correct order.

[Bug target/85904] configure issue cross compiling on netbsd, with patch

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-24
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to coypu from comment #0)
> Yes I will also email it to gcc-patches.

Please CC the libstdc++ list too.

[Bug c++/85907] New: AIX: static libstdc++ and exceptions causes abort

[brian at groose dot com]

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

Bug ID: 85907
   Summary: AIX: static libstdc++ and exceptions causes abort
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brian at groose dot com
  Target Milestone: ---

Created attachment 44178
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44178&action=edit
Pre-processed file

This bug seems to have been introduced in 4.9, and still exists in 8.1.0.  This
works as expected in 4.8.x.

If you statically link in libstdc++ on AIX, exception handling is broken.  The
first exception gets caught, but any later exceptions cause a core dump.

Example code:
# cat test.cpp
#include 
int main()
{
for (int i = 0; i < 5; ++i) {
try {
throw i;
} catch (int n) {
std::cout << "caught " << n << std::endl;
}
}
return 0;
}

Compile/Link:
g++ -o test test.cpp -static-libgcc -static-libstdc++ -lsupc++

Expected output:
caught 0
caught 1
caught 2
caught 3
caught 4

Actual output:
caught 0
IOT/Abort trap (core dumped)



Using built-in specs.
COLLECT_GCC=/opt/act-gcc-5.3.0a/bin/g++
COLLECT_LTO_WRAPPER=/opt/act-gcc-5.3.0a/libexec/gcc/powerpc-ibm-aix6.1.8.0/5.3.0/lto-wrapper
Target: powerpc-ibm-aix6.1.8.0
Configured with: /opt/jenkins/bg/gcc/act-gcc-5.3.0a-sandbox/gcc-5.3.0/configure
--prefix=/opt/act-gcc-5.3.0a --enable-languages=c,c++
--with-pkgversion=act-gcc-5.3.0a
Thread model: aix
gcc version 5.3.0 (act-gcc-5.3.0a)



I found a patch that fixes this at https://patchwork.ozlabs.org/patch/745138/

*** unwind-dw2-fde.c2018-05-21 17:56:34.0 -0400
--- unwind-dw2-fde.c2018-05-22 10:29:07.0 -0400
***
*** 1054,1060 
--- 1054,1080 
f = search_object (ob, pc);
if (f)
  goto fini;
+   /* In an ideal world, even on AIX, we could break here because
+  objects would not overlap.  But the larger an application is,
+  the more likely an "overlap" may happen (on AIX) because of:
+  - Shared libraries do export the FDE symbols ("_GLOBAL__F*"),
+which is a bug in their build system, out of gcc's control.
+  - Other shared libraries, or the main executable, may contain
+identical or similar object files - which is suboptimal, but
+may be intentional.  However, exporting their FDE symbols,
+which may have identical symbol names as in their original
+shared libraries, again is a bug in their build system, but
+still out of gcc's control.
+  - When enabled, run time linking may redirect adresses of
+duplicate FDE symbols from their original shared library's
+address range into another shared library's or the main
+executable's address range, when they share the same FDE
+symbol name.
+  This results in address ranges being registered by different
+  object to potentially overlap.  */
+ #if !(defined(_POWER) && defined(_AIX))
break;
+ #endif

[Bug c++/85842] [8/9 Regression] Bogus -Wreturn-type with generic lambda and constexpr if

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libfortran/85906] New: Conditional jump depends on uninitialized value in write_decimal / write_integer

[jhasse at bixense dot com]

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

Bug ID: 85906
   Summary: Conditional jump depends on uninitialized value in
write_decimal / write_integer
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jhasse at bixense dot com
  Target Milestone: ---

Created attachment 44177
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44177&action=edit
Initialize f->format in write_integer

r256034 modified write_integer to use write_decimal. In write_decimal
(write.c:808) the following line

  m = f->format == FMT_G ? -1 : f->u.integer.m;

checks format of the fnode struct. write_integer doesn't initialize that member
which results in a valgrind error "conditional jump or move depends on
uninitialized value".

The attached patch simply sets f->format to FMT_NONE in write_integer.

[Bug c++/85864] [8/9 Regression] template argument string literal operator with default argument doesnt work in templates

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/85864] [8/9 Regression] template argument string literal operator with default argument doesnt work in templates

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Thu May 24 14:29:05 2018
New Revision: 260674

URL: https://gcc.gnu.org/viewcvs?rev=260674&root=gcc&view=rev
Log:
PR c++/85864 - literal template and default template arg.

* pt.c (instantiation_dependent_r): Handle NONTYPE_ARGUMENT_PACK.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1y/udlit-char-template2.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/pt.c

[Bug c++/81420] When a reference is bound to a member in the base of a temporary, lifetime of the temporary is not extended

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Thu May 24 14:28:59 2018
New Revision: 260673

URL: https://gcc.gnu.org/viewcvs?rev=260673&root=gcc&view=rev
Log:
PR c++/81420 - not extending temporary lifetime.

* call.c (extend_ref_init_temps_1): Handle ARRAY_REF.
* class.c (build_base_path): Avoid redundant move of an rvalue.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/temp-extend1.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/call.c
branches/gcc-8-branch/gcc/cp/class.c

[Bug c++/85864] [8/9 Regression] template argument string literal operator with default argument doesnt work in templates

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu May 24 14:27:10 2018
New Revision: 260672

URL: https://gcc.gnu.org/viewcvs?rev=260672&root=gcc&view=rev
Log:
PR c++/85864 - literal template and default template arg.

* pt.c (instantiation_dependent_r): Handle NONTYPE_ARGUMENT_PACK.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/udlit-char-template2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug other/85898] I receive a segmentation fault due to an "internal compiler error"

[aeve at sas dot upenn.edu]

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

--- Comment #2 from Eve  ---
Hi Jakub -

Thank you for this information.  I will install the latest version of
cygwin and try again.  I appreciate your taking the time to reply.

eve

On Thu, May 24, 2018 at 2:41 AM, jakub at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85898
>
> Jakub Jelinek  changed:
>
>What|Removed |Added
> 
> 
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2018-05-24
>  CC||jakub at gcc dot gnu.org
>  Ever confirmed|0   |1
>
> --- Comment #1 from Jakub Jelinek  ---
> GCC 4.9 is not supported for almost two years now.
> If you can reproduce it with a supported compiler (right now 6.x or later),
> we'd need preprocessed source + full command line options, as mentioned in
> http://gcc.gnu.org/bugs.html .
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c/85902] -Wstringop-truncation false-positive

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-24
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=85619
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
The warning suppression logic looks for an assignment to the destination
immediately after strncpy and when it finds something else it assumes it's a
possible use of the destination.  We discussed (and even briefly experimented
with) enhancing the logic but it's a balancing act between false positives and
false negatives.  We may still come back to this (thus confirmed) but for now,
the best way to avoid the warning is to either nul-terminate the destination or
to decorate it with attribute nonstring to make it clear to GCC that it's not
expected to be nul-terminated.

The documentation problem is being tracked in bug 85619.

[Bug target/85905] New: cannot build for netbsd/alpha (with patch)

[coypu at sdf dot org]

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

Bug ID: 85905
   Summary: cannot build for netbsd/alpha (with patch)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

Created attachment 44176
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44176&action=edit
move linux specfile stuff to linux file.

when I build trunk I get in libgomp/config.log cannot create executables:

configure:3725: checking for C compiler default output file name
configure:3747: /tmp/build/./gcc/xgcc -B/tmp/build/./gcc/
-B/usr/local/alpha--netbsd/bin/ -B/usr/local/alpha--netbsd/lib/ -isystem
/usr/local/alpha--netbsd/include -isystem /usr/local/alpha--netbsd/sys-include
--sysroot=/home/fly/alpha/destdir.alpha/   -g -O2 -mieee   conftest.c  >&5
/home/fly/alpha/tooldir.NetBSD-8.99.17-amd64/alpha--netbsd/bin/ld: cannot find
crt1.o: No such file or directory
collect2: error: ld returned 1 exit status


I include two tm files that have effect on STARTFILE_SPEC definition.


alpha/elf.h:
#undef  STARTFILE_SPEC
#ifdef HAVE_LD_PIE
#define STARTFILE_SPEC \
  "%{!shared: %{pg|p:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}\
   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"

This is good for linux probably but I don't have crt1.o on netbsd.

netbsd-elf.h

#define NETBSD_STARTFILE_SPEC   \
  "%{!shared:   \
 %{pg:gcrt0%O%s}\
 %{!pg: \
   %{p:gcrt0%O%s}   \
   %{!p:crt0%O%s}}} \
   %:if-exists(crti%O%s)\
   %{static:%:if-exists-else(crtbeginT%O%s crtbegin%O%s)} \
   %{!static: \
 %{!shared:crtbegin%O%s} %{shared:crtbeginS%O%s}}"

#undef STARTFILE_SPEC
#define STARTFILE_SPEC NETBSD_STARTFILE_SPEC

This should work for all netbsd targets.

Attached is a patch to move alpha/elf.h definitions to linux.
I've previously sent it to gcc-patches but it didn't work so well. I'll resend.
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00887.html

I'm not very good at cross building and relying on netbsd's existing cross
tools to do these checks (binutils etc.). I don't know how to set it up for
openbsd, and they don't provide a similar toolchain. I have no alpha hardware
of my own but I tested this on someone's machine then.

[Bug c++/85847] [6/7/8 Regression] unexpected expression of kind template_id_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[6/7/8/9 Regression]|[6/7/8 Regression]
   |unexpected expression of|unexpected expression of
   |kind template_id_expr   |kind template_id_expr

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

[Bug c++/85847] [6/7/8/9 Regression] unexpected expression of kind template_id_expr

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Thu May 24 13:36:21 2018
New Revision: 260671

URL: https://gcc.gnu.org/viewcvs?rev=260671&root=gcc&view=rev
Log:
PR c++/85847
* init.c (build_new_1): Use fold_non_dependent_expr.  Use a dedicated
variable for its result.  Fix a condition.
(build_new): Use fold_non_dependent_expr.  Tweak a condition.

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

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

[Bug target/85894] PPC64LE alloca stack slot allocation allows memset to destroy the stack

[tuliom at linux dot ibm.com]

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

--- Comment #2 from Tulio Magno Quites Machado Filho  ---
I don't think this is a bug.  At least not an alloca() bug.
Let me explain:

(In reply to Rogerio Alves from comment #0)
> 0x3fffb7fb0908 :  stdur1,-128(r1)

The stack frame starts with 128B

> B+>0x3fffb7fb092c <+56>:  stdur9,-272(r1)

Increases to 128+272 = 400B.
Which I think is more than enough for this function.

> Notice, that stdu r9,-272(r1) move the stack pointer to alloca(te) the space
> on the stack. Now $r1 (stack pointer) is 0x3fffefd0 on my tests.

So, TOC, LR, CR and the backchain are stored in this new place.
There used to be a code copying these values to the new place, but as this
function never returns, the compiler is not copying the values to the new
place.

I don't think this optimization is wrong, though.
Copying the values to the new place wouldn't help anyway because the code
before alloca() still expects these values to be in their old place.

> After the 3th iteration he will execute the code above on address
> 0x30e0 which is the caller stack frame (previous sp) and will set
> the 32 bits after with zeros.

This is the old place of the backchain.  It's now reserved for alloca().
So, looks good to me.

> The caller stack frame is gone and when
> longjmp executes we get a Segmentation Fault at:
> 
> 0x3fffb7fb0954  ld  r2,24(r1)   

This is loading 0 because of glibc bug #21895, where the TOC pointer is not
restored in the stack frame for static programs.
That's why the the segfault happens.

[Bug libstdc++/85904] New: configure issue cross compiling on netbsd, with patch

[coypu at sdf dot org]

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

Bug ID: 85904
   Summary: configure issue cross compiling on netbsd, with patch
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

Created attachment 44175
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44175&action=edit
Fixes configure for me

Out of the box (+3 patches I would like to get merged) I got:

/home/fly/gcc/libstdc++-v3/libsupc++/new_opa.cc:62:1: error: 'void*
aligned_alloc(std::size_t, std::size_t)' was declared 'extern' and later
'static' [-fpermissive]
 aligned_alloc (std::size_t al, std::size_t sz)
 ^
In file included from /tmp/build/alpha--netbsd/libstdc++-v3/include/cstdlib:75,
 from
/tmp/build/alpha--netbsd/libstdc++-v3/include/stdlib.h:36,
 from /home/fly/gcc/libstdc++-v3/libsupc++/new_opa.cc:27:
/tmp/build/gcc/include-fixed/stdlib.h:254:7: note: previous declaration of
'void* aligned_alloc(size_t, size_t)'
 void *aligned_alloc(size_t, size_t);
   ^


I took the liberty to modify configure following similar platform examples.
with the patches I can build trunk.
Yes I will also email it to gcc-patches.

[Bug target/85903] [9 Regression] FAIL: gcc.target/i386/avx512dq-vcvtuqq2pd-2.c

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #3)
> Please try this patch:
> 
> --cut here--
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 8a80fa35067..9750708a80f 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -1248,11 +1248,8 @@
>  operands[2]));
> }
>   else if (memory_operand (operands[1], DImode))
> -   {
> - rtx tmp = gen_reg_rtx (V2DImode);
> - emit_insn (gen_vec_concatv2di (tmp, operands[1], const0_rtx));
> - emit_move_insn (operands[0], gen_lowpart (V4SImode, tmp));
> -   }
> +   emit_insn (gen_vec_concatv2di (gen_lowpart (V2DImode, operands[0]),
> + operands[1], const0_rtx));
>   else
> gcc_unreachable ();
>   DONE;
> --cut here--

It works.  Thanks.

[Bug target/85903] [9 Regression] FAIL: gcc.target/i386/avx512dq-vcvtuqq2pd-2.c

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
Please try this patch:

--cut here--
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 8a80fa35067..9750708a80f 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -1248,11 +1248,8 @@
 operands[2]));
}
  else if (memory_operand (operands[1], DImode))
-   {
- rtx tmp = gen_reg_rtx (V2DImode);
- emit_insn (gen_vec_concatv2di (tmp, operands[1], const0_rtx));
- emit_move_insn (operands[0], gen_lowpart (V4SImode, tmp));
-   }
+   emit_insn (gen_vec_concatv2di (gen_lowpart (V2DImode, operands[0]),
+ operands[1], const0_rtx));
  else
gcc_unreachable ();
  DONE;
--cut here--

[Bug target/85903] [9 Regression] FAIL: gcc.target/i386/avx512dq-vcvtuqq2pd-2.c

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
Need -mfpmath=sse:

make check-gcc RUNTESTFLAGS="--target_board='unix{-m32\ -march=slm\
-mfpmath=sse}' i386.exp=avx512dq-vcvtuqq2pd-2.c"

unless GCC is configured with --with-fpmath=sse.

[Bug c++/77513] -Wzero-as-null-pointer-constant vs 0, nullptr, NULL and __null

[falemagn at gmail dot com]

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

Fabio Alemagna  changed:

   What|Removed |Added

 CC||falemagn at gmail dot com

--- Comment #6 from Fabio Alemagna  ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to petschy from comment #0)
> > For c++11 and later code, why is NULL defined as __null, rather than 
> > nullptr?
> 
> Because defining NULL as nullptr would violate the requirements of the
> standard, which very intentionally says that NULL is an integral constant
> expression, not nullptr.

I don't know how autoritative is it, but cppreference.com says that since
C++11,  NULL is

an integer literal with value zero, or a prvalue of type std::nullptr_t

See: http://en.cppreference.com/w/cpp/types/NULL

[Bug target/85903] [9 Regression] FAIL: gcc.target/i386/avx512dq-vcvtuqq2pd-2.c

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Well, movdi2sse post-reload splitter won't have any chance with:

 else if (memory_operand (operands[1], DImode))
   {
 rtx tmp = gen_reg_rtx (V2DImode);
 emit_insn (gen_vec_concatv2di (tmp, operands[1], const0_rtx));
 emit_move_insn (operands[0], gen_lowpart (V4SImode, tmp));
   }

So, it is invalid to generate pseudo after reload.

[Bug target/85903] New: [9 Regression] FAIL: gcc.target/i386/avx512dq-vcvtuqq2pd-2.c

[hjl.tools at gmail dot com]

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

Bug ID: 85903
   Summary: [9 Regression] FAIL:
gcc.target/i386/avx512dq-vcvtuqq2pd-2.c
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i686-pc-linux-gnu

r260614 caused:

FAIL: gcc.target/i386/avx512dq-vcvtuqq2pd-2.c (internal compiler error)
FAIL: gcc.target/i386/avx512dq-vcvtuqq2pd-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512vl-pr79299-1.c (internal compiler error)
FAIL: gcc.target/i386/avx512vl-pr79299-1.c (test for excess errors)
FAIL: gcc.target/i386/avx512vl-vcvtuqq2pd-2.c (internal compiler error)
FAIL: gcc.target/i386/avx512vl-vcvtuqq2pd-2.c (test for excess errors)

with -m32 -march=slm

[hjl@gnu-cfl-1 gcc]$  /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/avx512dq-vcvtuqq2pd-2.c
-m32 -march=slm -fno-diagnostics-show-caret -fdiagnostics-color=never -O2
-mavx512dq -lm -o ./avx512dq-vcvtuqq2pd-2.exe
during RTL pass: split2
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/avx512dq-vcvtuqq2pd-2.c:
In function \u2018test_512\u2019:
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/avx512dq-vcvtuqq2pd-2.c:51:1:
internal compiler error: in gen_reg_rtx, at emit-rtl.c:1155
0xb01806 gen_reg_rtx(machine_mode)
/export/gnu/import/git/sources/gcc/gcc/emit-rtl.c:1155
0x1862b1b gen_split_421(rtx_insn*, rtx_def**)
/export/gnu/import/git/sources/gcc/gcc/config/i386/sse.md:1252
0x1abf2a9 split_insns(rtx_def*, rtx_insn*)
/export/gnu/import/git/sources/gcc/gcc/config/i386/sse.md:1238
0xb08a7f try_split(rtx_def*, rtx_insn*, int)
/export/gnu/import/git/sources/gcc/gcc/emit-rtl.c:3851
0xf07e90 split_insn
/export/gnu/import/git/sources/gcc/gcc/recog.c:2892
0xf081af split_all_insns()
/export/gnu/import/git/sources/gcc/gcc/recog.c:2996
0xf0a0e2 execute
/export/gnu/import/git/sources/gcc/gcc/recog.c:3946
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-cfl-1 gcc]$

[Bug c/85902] New: -Wstringop-truncation false-positive

[igor.chorazewicz at intel dot com]

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

Bug ID: 85902
   Summary: -Wstringop-truncation false-positive
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: igor.chorazewicz at intel dot com
  Target Milestone: ---

Observed in fedora 28 - gcc 8.1.1 20180502 (Red Hat 8.1.1-1).

Consider the following code:

int main(int argc, char *argv[])
{
char dst[10];

strncpy(dst, argv[0], sizeof(dst));
if (dst[sizeof(dst) - 1] == '\0')
printf("%s\n", dst);

return 0;
}

When compiled with '-Wall -O2' gcc gives following warning:
warning: 'strncpy' specified bound 10 equals destination size
[-Wstringop-truncation]

I think this code handles truncation correctly and gcc should not emit this
warning.
Warning persists even if we change the code to the following (which makes
buffer overflow impossible):

int main(int argc, char *argv[])
{
char dst[10];

strncpy(dst, argv[0], sizeof(dst));
if (dst[sizeof(dst) - 1] == '\0')
printf("%s\n", dst);
else
dst[sizeof(dst) - 1] = '\0';

return 0;
}

In my project, this warning is triggered from following function,
which is attempt to implement safer strcpy:

static inline int
util_safe_strcpy(char *dst, const char *src, size_t max_length)
{
if (max_length == 0)
return -1;

strncpy(dst, src, max_length);

return dst[max_length - 1] == '\0' ? 0 : -1;
}

Moreover -Wstringop-truncation is not documented to be in -Wall:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

[Bug tree-optimization/85891] [6 Regression] Simple loop is not SLP-vectorized after r196872

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Thu, 24 May 2018, jason.vas.dias at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85891
> 
> --- Comment #7 from Jason Vas Dias  ---
> Aha!
> Yes, I was experimenting with the new '-march=haswell' and
> '-mtune=intel' options
> (  which seem to me to be the wrong way round - shouldn't 'haswell' be an
>'-mtune' option and 'intel' be an '-march' option ? but this is not
> the case,
>   according to documentation.
> ) .
> GCC 6.4.1 was configured with :
> 
> ./configure \
>--prefix=/usr/local --libdir=/usr/local/lib64 --enable-languages=all \
>   --enable-targets=all --enable-multilib --enable-threads=posix --enable-lto \
>   --with-cpu-64=intel --with-cpu-32=generic \
>   --with-arch-64=haswell --with-tune-64=intel --with-arch-32=i686 \
>   --with-fp=sse+387 --with-tune-32=generic --enable-shared \
>   --with-pic --with-gmp=/usr/local --with-isl=/usr/local \
>   --with-cloog=/usr/local --with-mpc=/usr/local --with-isl=/usr/local \
>   --with-system-zlib --with-gnu-ld --with-gnu-as --enable-serial-configure \
>   --host=x86_64-linux-gnu --build=x86_64-linux-gnu --target=x86_64-linux-gnu
> '
> 
> What I am trying to achieve is that the DEFAULT 64-bit platform for the
> compiler
> (the target the compiler builds for without any  '-m=yyy' options)   
> should
> be '-march=haswell -mtune=intel', which  I think should be the equivalent
> to the older options  '-march=x86-64 -mtune=haswell' , and to
>  '-mtune=native' on this platform - please let me know if this is not the
> case .
> 
> The 5.5.0 & 7.3.1 compilers were built with
>   '--with-arch64=x86-64 --with-cpu64=haswell' ,
> but re-reading the updated 6.4.1 '-mtune'/'-march' documentation led
> me to believe
> that the new '--with-arch-64=haswell --with-tune-64=intel' options were
> more appropriate . I guess not ?
> (The 5.5.0 and 7.3.1 builds are 6months & 2months old, before the
> '-march=haswell' support.
> ).
> 
> I will try rebuilding 6.3.1 with '--with-arch64=x86-64
> --with-cpu64=haswell' and
> retest.  Thanks!

The testsuite is mostly "tuned" to the defaults, that is -march=x86-64
and -mtune=generic.  So you likely won't have luck with the above
choice either.

The testcase could be improved to handle the situation more gracefully
but really there's no point on the old GCC 6 branch.

[Bug c++/66476] Erroneous initializer_list lifetime extension from temporary initializer_list

[ed at catmur dot uk]

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

Ed Catmur  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Ed Catmur  ---
Ah wait, guaranteed copy elision since C++17 should fix this, right? So g++ is
actually correct now, even if it was wrong before.

[Bug tree-optimization/85891] [6 Regression] Simple loop is not SLP-vectorized after r196872

[jason.vas.dias at gmail dot com]

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

--- Comment #7 from Jason Vas Dias  ---
Aha!
Yes, I was experimenting with the new '-march=haswell' and
'-mtune=intel' options
(  which seem to me to be the wrong way round - shouldn't 'haswell' be an
   '-mtune' option and 'intel' be an '-march' option ? but this is not
the case,
  according to documentation.
) .
GCC 6.4.1 was configured with :

./configure \
   --prefix=/usr/local --libdir=/usr/local/lib64 --enable-languages=all \
  --enable-targets=all --enable-multilib --enable-threads=posix --enable-lto \
  --with-cpu-64=intel --with-cpu-32=generic \
  --with-arch-64=haswell --with-tune-64=intel --with-arch-32=i686 \
  --with-fp=sse+387 --with-tune-32=generic --enable-shared \
  --with-pic --with-gmp=/usr/local --with-isl=/usr/local \
  --with-cloog=/usr/local --with-mpc=/usr/local --with-isl=/usr/local \
  --with-system-zlib --with-gnu-ld --with-gnu-as --enable-serial-configure \
  --host=x86_64-linux-gnu --build=x86_64-linux-gnu --target=x86_64-linux-gnu
'

What I am trying to achieve is that the DEFAULT 64-bit platform for the
compiler
(the target the compiler builds for without any  '-m=yyy' options)   should
be '-march=haswell -mtune=intel', which  I think should be the equivalent
to the older options  '-march=x86-64 -mtune=haswell' , and to
 '-mtune=native' on this platform - please let me know if this is not the
case .

The 5.5.0 & 7.3.1 compilers were built with
  '--with-arch64=x86-64 --with-cpu64=haswell' ,
but re-reading the updated 6.4.1 '-mtune'/'-march' documentation led
me to believe
that the new '--with-arch-64=haswell --with-tune-64=intel' options were
more appropriate . I guess not ?
(The 5.5.0 and 7.3.1 builds are 6months & 2months old, before the
'-march=haswell' support.
).

I will try rebuilding 6.3.1 with '--with-arch64=x86-64
--with-cpu64=haswell' and
retest.  Thanks!


On 24/05/2018, rguenth at gcc dot gnu.org  wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85891
>
> --- Comment #6 from Richard Biener  ---
> The log file shows the loop was already vectorized by loop vectorization.
> How
> did you configure gcc?  It might be you configured a default -march/tune
> that
> doesn't match the testcase expectation (and the testcase could probably use
> -ftree-slp-vectorize instead of -ftree-vectorize).
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/85901] New: Error message contains "#'offset_type' not supported by simple_type_specifier#)#'offset_type' not supported by direct_abstract_declarator#"

[ensadc at mailnesia dot com]

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

Bug ID: 85901
   Summary: Error message contains "#'offset_type' not supported
by simple_type_specifier#)#'offset_type' not supported
by direct_abstract_declarator#"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ensadc at mailnesia dot com
  Target Milestone: ---

https://wandbox.org/permlink/IQV1PEfIFY8M5T5C

template struct A;

template
struct A {
template
static auto c(int U::*p, TT o) -> decltype(o.*p);
};

struct X {};

int x = A::c();


prog.cc:11:24: error: no matching function for call to 'A::c()'
 int x = A::c();
^
prog.cc:6:17: note: candidate: 'template static decltype
(A<#'offset_type' not supported by simple_type_specifier#)#'offset_type' not
supported by direct_abstract_declarator#>::c::o.*A<#'offset_type' not supported
by simple_type_specifier#)#'offset_type' not supported by
direct_abstract_declarator#>::c::p) A::c(int U::*, TT) [with TT = TT;
U = X]'
 static auto c(int U::*p, TT o) -> decltype(o.*p);
 ^
prog.cc:6:17: note:   template argument deduction/substitution failed:
prog.cc:11:24: note:   candidate expects 2 arguments, 0 provided
 int x = A::c();
^

"#'offset_type' not supported by simple_type_specifier#)#'offset_type' not
supported by direct_abstract_declarator#" shouldn't be present in the error
message.

Maybe the nested-name-specifier before o and p are all redundant. That is, it
should be just "decltype(o.*p)", not
"decltype(A::c::o.*A::c::p)".

[Bug target/85900] [9 Regression] ICEs after revision r260547 on darwin.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |9.0

--- Comment #1 from Richard Biener  ---
Note the rev. is going to be backported so watch out there as well.

[Bug tree-optimization/85891] [6 Regression] Simple loop is not SLP-vectorized after r196872

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
The log file shows the loop was already vectorized by loop vectorization.  How
did you configure gcc?  It might be you configured a default -march/tune that
doesn't match the testcase expectation (and the testcase could probably use
-ftree-slp-vectorize instead of -ftree-vectorize).

[Bug tree-optimization/85891] [6 Regression] Simple loop is not SLP-vectorized after r196872

[jason.vas.dias at gmail dot com]

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

--- Comment #5 from Jason Vas Dias  ---
Could it be an issue to do with running on different hardware?
The CPU on the machine is a rather old 4-core (8 with HyperThreading)
Haswell :



processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 60
model name  : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
stepping: 3
microcode   : 0x22
cpu MHz : 3400.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc a
perfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3
sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb tpr_shadow vnmi
flexpriority ept vpid
fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat
pln pts
bogomips: 6784.22
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

[Bug middle-end/85881] [9 Regression] FAIL: g++.dg/pr80481.C -std=gnu++11 scan-assembler-not vmovaps

[andrey.y.guskov at intel dot com]

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

--- Comment #6 from Andrey Guskov  ---
Also affected: gcc.dg/guality/pr58791-4.c

[Bug tree-optimization/85891] [6 Regression] Simple loop is not SLP-vectorized after r196872

[jason.vas.dias at gmail dot com]

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

--- Comment #4 from Jason Vas Dias  ---
Same commands run by GCC 5.5.0 or GCC 7.3.1 succeed:

$ g++5 slp-pr56812.cc -nostdinc++ -std=c++98 -O2 -ftree-vectorize
-fno-vect-cost-model -msse2 -fdump-tree-slp-details=gcc5.out -O3 -funroll-loops
-fvect-cost-model=dynamic -S -o slp-pr56812.gcc5.s
$ grep 'basic block vectorized' gcc5.out
slp-pr56812.cc:17:16: note: basic block vectorized
$ gcc_7_3_env
$ g++7 slp-pr56812.cc -nostdinc++ -std=c++14 -O2 -ftree-vectorize
-fno-vect-cost-model -msse2 -fdump-tree-slp-details=gcc7.out -O3 -funroll-loops
-fvect-cost-model=dynamic -S -o slp-pr56812.gcc7.s
$ grep 'basic block vectorized' gcc7.out
slp-pr56812.cc:18:1: note: basic block vectorized

[Bug libstdc++/69769] arithmetic operation on pointer to a function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/85886] std::atomic<> doesn't have value_type and difference_type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/85891] [6 Regression] Simple loop is not SLP-vectorized after r196872

[jason.vas.dias at gmail dot com]

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

--- Comment #3 from Jason Vas Dias  ---
Created attachment 44174
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44174&action=edit
slp1 log file

Here is the slp1 log file produced by command:
$
/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/testsuite/g++/../../xg++
-B/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/testsuite/g++/../../
/home/devel/OS/gcc-6-branch/gcc/testsuite/g++.dg/vect/slp-pr56812.cc
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/include/x86_64-linux-gnu
-I/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/include
-I/home/devel/OS/gcc-6-branch/libstdc++-v3/libsupc++
-I/home/devel/OS/gcc-6-branch/libstdc++-v3/include/backward
-I/home/devel/OS/gcc-6-branch/libstdc++-v3/testsuite/util -fmessage-length=0
-std=c++14 -O2 -ftree-vectorize -fno-vect-cost-model -msse2
-fdump-tree-slp-details -O3 -funroll-loops -fvect-cost-model=dynamic -S -o
slp-pr56812.s


It does not contain the string 'basic block vectorized', so the test fails.

[Bug tree-optimization/85793] [8/9 Regression][AARCH64] ICE in verify_gimple during GIMPLE pass vect.

[amker at gcc dot gnu.org]

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

--- Comment #4 from bin cheng  ---
Author: amker
Date: Thu May 24 09:49:43 2018
New Revision: 260636

URL: https://gcc.gnu.org/viewcvs?rev=260636&root=gcc&view=rev
Log:
Backport from mainline
2018-05-17  Bin Cheng  
Richard Biener  

PR tree-optimization/85793
* tree-vect-stmts.c (vectorizable_load): Handle 1 element-wise load
for VMAT_ELEMENTWISE.

gcc/testsuite
2018-05-17  Bin Cheng  

PR tree-optimization/85793
* gcc.dg/vect/pr85793.c: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr85793.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree-vect-stmts.c

[Bug tree-optimization/85891] [6 Regression] Simple loop is not SLP-vectorized after r196872

[jason.vas.dias at gmail dot com]

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

--- Comment #2 from Jason Vas Dias  ---
Created attachment 44173
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44173&action=edit
log file produced by 'make check-g++ 'RUNTESTFLAGS=vect.exp=slp-pr56812*'

Log file showing test failures as requested

[Bug target/85900] New: [9 Regression] ICEs after revision r260547 on darwin.

[dominiq at lps dot ens.fr]

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

Bug ID: 85900
   Summary: [9 Regression] ICEs after revision r260547 on darwin.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: hjl at gcc dot gnu.org, iains at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin17
Target: x86_64-apple-darwin17
 Build: x86_64-apple-darwin17

After revision r260547 the test gcc.dg/torture/pr48044.c gives the following
ICE when compiled on darwin:

/opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr48044.c:10:1: internal compiler
error: in get, at cgraph.h:1298
 extern int c __asm__ (ASMNAME ("a")) __attribute__ ((alias ("b")));

It used to give

/opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr48044.c:10:12: error: only weak
aliases are supported in this configuration
 extern int c __asm__ (ASMNAME ("a")) __attribute__ ((alias ("b")));
^

In a similar way the test use in gcc/testsuite/lib/target-supports.exp for

proc check_alias_available

#ifdef __cplusplus
extern "C"
#endif
void g() {} void f() __attribute__((alias("g")));

gives the ICE

alias.c:4:1: internal compiler error: Segmentation fault: 11
 void g() {} void f() __attribute__((alias("g")));
 ^~~~

It used to give

alias.c:4:18: error: only weak aliases are supported in this configuration
 void g() {} void f() __attribute__((alias("g")));
  ^
I think this explain the numerous new errors I see in the test suite.

[Bug c++/66476] Erroneous initializer_list lifetime extension from temporary initializer_list

[ed at catmur dot uk]

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

Ed Catmur  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #2 from Ed Catmur  ---
Yes... but the initializer_list that the array backs is itself temporary; it
has lifetime only for the duration of the call to the copy constructor. 

From https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48562#c6 :

> I think that a warning against "({...})" would be useful too
>// fine
>initializer_list a{1, 2, 3};
>// this is bad
>initializer_list b({1, 2, 3});
> Second one is bad because it will destroy the array after initializing 'b', 
> and won't lengthen the lifetime (because it will use the copy/move
> constructor).

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[avieira at gcc dot gnu.org]

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

--- Comment #8 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Thu May 24 08:53:39 2018
New Revision: 260635

URL: https://gcc.gnu.org/viewcvs?rev=260635&root=gcc&view=rev
Log:
PR target/83009: Relax strict address checking for store pair lanes

The operand constraint for the memory address of store/load pair lanes was
enforcing strictly hardware registers be allowed as memory addresses.  We want
to relax that such that these patterns can be used by combine.  During register
allocation the register constraint will enforce the correct register is chosen.

gcc
2018-05-24  Andre Vieira  

PR target/83009
* config/aarch64/predicates.md (aarch64_mem_pair_lanes_operand): Make
address check not strict.

gcc/testsuite
2018-05-24  Andre Vieira  

PR target/83009
* gcc/target/aarch64/store_v2vec_lanes.c: Add extra tests.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/predicates.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c

[Bug gcov-profile/84846] GCOV intermediate format improvements

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

--- Comment #6 from Martin Liška  ---
(In reply to Eric Botcazou from comment #5)
> Reopening, displaying the current working directory in the .gcov file breaks
> automatic coverage testing, where you compare it against a fixed baseline.
> 
> Please at least make this optional in the .gcov file.

Will do that.

[Bug tree-optimization/85891] [6 Regression] Simple loop is not SLP-vectorized after r196872

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |WAITING
Version|unknown |6.3.1
   Keywords||missed-optimization,
   ||needs-bisection
   Last reconfirmed||2018-05-24
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|[6.4.1 regression] Simple   |[6 Regression] Simple loop
   |loop is not SLP-vectorized  |is not SLP-vectorized after
   |after r196872   |r196872
   Target Milestone|--- |6.5

--- Comment #1 from Richard Biener  ---
The test works fine for me on x86_64 Linux (openSUSE Leap 42.2) on the GCC 6
branch (r260441).  I don't see anything host specific in it.

Please cut&paste from the testsuite log the compiler commands and attach the
slp1 dump file.

[Bug c++/85890] [7 Regression] cc1plus runs out of memory in recursive Fibonacci computation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||6.4.0, 7.1.0, 7.2.0, 8.1.0
   Keywords||compile-time-hog,
   ||memory-hog, needs-bisection
   Last reconfirmed||2018-05-24
 Ever confirmed|0   |1
Summary|cc1plus runs out of memory  |[7 Regression] cc1plus runs
   |in recursive Fibonacci  |out of memory in recursive
   |computation |Fibonacci computation
   Target Milestone|--- |7.4
  Known to fail||7.3.0, 7.3.1

--- Comment #1 from Richard Biener  ---
Confirmed.  GCC 8 and GCC 6 finish this in 0.02s and with 21MB memory use.

It's a regression on the branch.

[Bug debug/85893] gcc.dg/guality/pr41616-1.c FAILs with -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||8.1.0
Version|unknown |7.3.1
   Keywords||lto
   Last reconfirmed||2018-05-24
  Component|lto |debug
 Ever confirmed|0   |1
Summary|[regression] Variables  |gcc.dg/guality/pr41616-1.c
   |promoted to Gimple  |FAILs with -flto
   |registers by aliasing are   |
   |not getting debug   |
   |statements (if -flto used). |
  Known to fail||7.3.1

--- Comment #1 from Richard Biener  ---
Confirmed.  Note they no longer FAIL with GCC 8+.

[Bug fortran/85895] [6/7/8/9 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3518

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug tree-optimization/85897] missing strncmp optimization for bound in known range

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-24
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  We can simply use the MAX of a range to do the compile-time
evaluation
(but only for compile-time equal result then optimize away the comparison).
For known-false compares we'd have to test all possible substrings.

[Bug gcov-profile/84846] GCOV intermediate format improvements

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ebotcazou at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #5 from Eric Botcazou  ---
Reopening, displaying the current working directory in the .gcov file breaks
automatic coverage testing, where you compare it against a fixed baseline.

Please at least make this optional in the .gcov file.