[Bug target/92042] Missing rcpss optimization

[crazylht at gmail dot com]

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

Hongtao.liu  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #2 from Hongtao.liu  ---


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

[Bug middle-end/31723] Use reciprocal and reciprocal square root with -ffast-math

[crazylht at gmail dot com]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #30 from Hongtao.liu  ---
*** Bug 92042 has been marked as a duplicate of this bug. ***

[Bug target/92042] Missing rcpss optimization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
This is done on purpose as vrcpss is too weak and needs a few extra steps. 
This means the performance would be less.

  You need to use -mrecip=div to get rcpss with the extra steps.

[Bug target/92042] New: Missing rcpss optimization

[crazylht at gmail dot com]

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

Bug ID: 92042
   Summary: Missing rcpss optimization
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com, lili.cui at intel dot com,
skpgkp2 at gmail dot com, wwwhhhyyy333 at gmail dot com
  Target Milestone: ---

For testcase

float foo (float f1)
{
  return 1.0 / f1 ;
}

gcc20190919 -Ofast -march=skylake-avx512 -S test.c -S

got

foo:
vmovss  .LC0(%rip), %xmm1
vdivss  %xmm0, %xmm1, %xmm0
ret

But sse/avx has rcpss/vrcpss, which could be better to generate

foo:
   vrcpss %xmm0, %xmm0, %xmm0
   ret

[Bug target/92041] m68k optimizations (-O2, -O3 or -Ofast) generates wrong code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup.

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

[Bug middle-end/78074] gcc-6.2.0 miscompiles calloc reimplementation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||djipi.mari at gmail dot com

--- Comment #2 from Andrew Pinski  ---
*** Bug 92041 has been marked as a duplicate of this bug. ***

[Bug target/92041] New: m68k optimizations (-O2, -O3 or -Ofast) generates wrong code

[djipi.mari at gmail dot com]

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

Bug ID: 92041
   Summary: m68k optimizations (-O2, -O3 or -Ofast) generates
wrong code
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: djipi.mari at gmail dot com
  Target Milestone: ---
  Host: x86
Target: m68k-elf

This code:
void *calloc(size_t num_elements, size_t size)
{
void *ptr = malloc(num_elements*size);

if (ptr)
{
memset(ptr, 0, (num_elements*size));
}

return  ptr;
}

Generates this assembly when using -O2, -O3 or -Ofast:
calloc:
move.l 8(%sp),%d0
moveq #1,%d1
move.l %d1,8(%sp)
move.l %d0,-(%sp)
move.l 8(%sp),-(%sp)
jsr __mulsi3
addq.l #8,%sp
move.l %d0,4(%sp)
jra calloc

The issue appears since the 9.1.0, previous versions do not have such issues.

[Bug c++/92040] New: Type requirements don't appear to work when a type doesn't exist.

[cjdb.ns at gmail dot com]

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

Bug ID: 92040
   Summary: Type requirements don't appear to work when a type
doesn't exist.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cjdb.ns at gmail dot com
  Target Milestone: ---

Created attachment 47011
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47011=edit
Requested file

# GCC version

g++ (GCC) 10.0.0 20191009 (experimental)

# System type

Ubuntu on WSL

No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 19.04
Release:19.04
Codename:   disco

# GCC built with

export CC=/usr/bin/clang-9
export CXX=/usr/bin/clang++-9
export CFLAGS='-w -O3 -DNDEBUG -g0 -fdiagnostics-color=always -fuse-ld=lld'
export CXXFLAGS='-w -O3 -DNDEBUG -g0 -fdiagnostics-color=always -fuse-ld=lld'
export LDFLAGS='-fuse-ld=lld'

../gcc/configure --enable-languages=c,c++  \
 --disable-bootstrap   \
 --disable-libada  \
 --disable-libgomp \
 --disable-libquadmath \
 --disable-libquadmath-support \
 --disable-multilib\
 --disable-nls \
 --disable-werror

make -j6
sudo make install-strip -j6

# Minimal repro

```cpp
template
constexpr void example()
{
constexpr auto result = requires { typename T::value_type; };
static_assert(not result);
}

int main()
{
   struct s{};
   example();
}
```

Built using: /usr/local/bin/g++ -std=c++2a test.cpp

# Diagnostic

```
test.cpp: In instantiation of 'constexpr void example() [with T = main()::s]':
test.cpp:11:15:   required from here
test.cpp:4:49: error: no type named 'value_type' in 'struct main()::s'
4 | constexpr auto result = requires { typename T::value_type; };
  |
```

[Bug middle-end/91691] Cross compiling glibc produces a false maybe-uninitialized error

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-10
 CC||wilson at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jim Wilson  ---
I can reproduce using gcc-8 and gcc-9 but not mainline.  I'm using gcc options:
-std=gnu11 -fgnu89-inline  -mcmodel=medlow -g -O2 -Wall -Wwrite-strings -Wundef 
-fmerge-all-constants -frounding-math -fno-stack-protector -Wstrict-prototypes
-
Wold-style-definition -fmath-errno   -fPIC   -ftls-model=initial-exec \
tmp.i -fdump-tree-all -fdump-ipa-all 

Bisecting on mainline shows that the new IPA SRA pass added Sept 20 fixed this.
Without that patch, I see that total_deadline is being decomposed, but
apparently there is something wrong with the tracking info. If I add
-fno-ipa-sra the warning goes away.

The new IPA-SRA is too big of a patch to backport, so it looks like this will
have to remain unfixed on the gcc-8 and gcc-9 branches.

[Bug target/92038] Extremely inefficient x86_64 code for trivally copyable types passed in registers.

[maxim.yegorushkin at gmail dot com]

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

--- Comment #2 from Maxim Egorushkin  ---
The competition often generates ideal code, but gcc team doesn't seem to care
at all.

[Bug target/92038] Extremely inefficient x86_64 code for trivally copyable types passed in registers.

[maxim.yegorushkin at gmail dot com]

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

--- Comment #1 from Maxim Egorushkin  ---
I have reported a few bugs this year related to poor code generation:

https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=SUSPENDED_status=WAITING_status=REOPENED_status=RESOLVED_status=VERIFIED_status=CLOSED_known_to_fail_type=allwords_known_to_work_type=allwords=target=egorushkin=1=substring=gcc_format=advanced=---

I consider these to be serious performance shortcomings. Are there any plans to
fix those please?

[Bug c++/68957] Wrong overload resolution for unscoped enums with fixed underlying type

[rogero at howzatt dot demon.co.uk]

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

--- Comment #3 from Roger Orr  ---
Thanks Jon.

[Bug middle-end/92037] [10 Regression] LTO bootstrap broken in selftests

[trass3r at gmail dot com]

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

Trass3r  changed:

   What|Removed |Added

 CC||trass3r at gmail dot com

--- Comment #2 from Trass3r  ---
Same here with
CPPFLAGS="-pipe -O3 -g0 -flto -march=haswell" CC=gcc-9 CXX=g++-9
../sources/gcc-git/configure --enable-languages=c,c++ --enable-lto
--enable-plugins --disable-nls --disable-multilib --disable-bootstrap
on Ubuntu 19.04:

./gcc/xgcc -B..././gcc/ -xc -nostdinc /dev/null -S -o /dev/null
-fself-test=../../sources/gcc-git/gcc/testsuite/selftests
cc1: internal compiler error: Segmentation fault
0x147094f crash_signal
../../sources/gcc-git/gcc/toplev.c:326
0x195ad29 cgraph_node::create(tree_node*)
../../sources/gcc-git/gcc/cgraph.h:2658
0x1958947 cgraph_node::get_create(tree_node*)
../../sources/gcc-git/gcc/cgraph.c:545
0x1926c38 selftest::test_capture_of_dump_calls(selftest::line_table_case
const&) [clone .lto_priv.0]
../../sources/gcc-git/gcc/dumpfile.c:2236
0x18f5fb3 selftest::dumpfile_c_tests()
../../sources/gcc-git/gcc/input.c:3555
0x8d3c31 selftest::run_tests()
../../sources/gcc-git/gcc/selftest-run-tests.c:62
0x1470973 toplev::run_self_tests()
../../sources/gcc-git/gcc/toplev.c:2230

[Bug tree-optimization/90879] fold zero-equality of strcmp between a longer string and a smaller array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Patch committed in r276773.

[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations

[msebor at gcc dot gnu.org]

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

Bug 90879 Summary: fold zero-equality of strcmp between a longer string and a 
smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90879

   What|Removed |Added

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

[Bug tree-optimization/90879] fold zero-equality of strcmp between a longer string and a smaller array

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Wed Oct  9 21:35:11 2019
New Revision: 276773

URL: https://gcc.gnu.org/viewcvs?rev=276773=gcc=rev
Log:
PR tree-optimization/90879 - fold zero-equality of strcmp between a longer
string and a smaller array

gcc/c-family/ChangeLog:

PR tree-optimization/90879
* c.opt (-Wstring-compare): New option.

gcc/testsuite/ChangeLog:

PR tree-optimization/90879
* gcc.dg/Wstring-compare-2.c: New test.
* gcc.dg/Wstring-compare.c: New test.
* gcc.dg/strcmpopt_3.c: Scan the optmized dump instead of strlen.
* gcc.dg/strcmpopt_6.c: New test.
* gcc.dg/strlenopt-65.c: Remove uinnecessary declarations, add
test cases.
* gcc.dg/strlenopt-66.c: Run it.
* gcc.dg/strlenopt-68.c: New test.

gcc/ChangeLog:

PR tree-optimization/90879
* builtins.c (check_access): Avoid using maxbound when null.
* calls.c (maybe_warn_nonstring_arg): Adjust to get_range_strlen
change.
* doc/invoke.texi (-Wstring-compare): Document new warning option.
* gimple-fold.c (get_range_strlen_tree): Make setting maxbound
conditional.
(get_range_strlen): Overwrite initial maxbound when non-null.
* gimple-ssa-sprintf.c (get_string_length): Adjust to get_range_strlen
changes.
* tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Same.
(used_only_for_zero_equality): New function.
(handle_builtin_memcmp): Call it.
(determine_min_objsize): Return an integer instead of tree.
(get_len_or_size, strxcmp_eqz_result): New functions.
(maybe_warn_pointless_strcmp): New function.
(handle_builtin_string_cmp): Call it.  Fold zero-equality of strcmp
between a longer string and a smaller array.
(get_range_strlen_dynamic): Overwrite initial maxbound when non-null.


Added:
trunk/gcc/testsuite/gcc.dg/Wstring-compare-2.c
trunk/gcc/testsuite/gcc.dg/Wstring-compare.c
trunk/gcc/testsuite/gcc.dg/strcmpopt_6.c
trunk/gcc/testsuite/gcc.dg/strlenopt-69.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/calls.c
trunk/gcc/doc/invoke.texi
trunk/gcc/gimple-fold.c
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/strcmpopt_3.c
trunk/gcc/testsuite/gcc.dg/strlenopt-65.c
trunk/gcc/testsuite/gcc.dg/strlenopt-66.c
trunk/gcc/tree-ssa-strlen.c

[Bug tree-optimization/92039] [10 Regression] Spurious -Warray-bounds warnings building 32-bit glibc

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-09
 CC||law at redhat dot com
 Ever confirmed|0   |1

--- Comment #1 from Jeffrey A. Law  ---
My tester tripped this as well.  Confirming.

[Bug c++/91364] Implement P0388R4: Permit conversions to arrays of unknown bound

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Implemented for GCC 10.

[Bug c++/88323] implement C++20 language features.

[mpolacek at gcc dot gnu.org]

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

Bug 91364 Summary: Implement P0388R4: Permit conversions to arrays of unknown 
bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91364

   What|Removed |Added

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

[Bug c++/88128] G++ should implement CWG 330

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
Implemented for GCC 10.

[Bug c++/91364] Implement P0388R4: Permit conversions to arrays of unknown bound

[mpolacek at gcc dot gnu.org]

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

Bug 88128 Summary: G++ should implement CWG 330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88128

   What|Removed |Added

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

[Bug c++/91364] Implement P0388R4: Permit conversions to arrays of unknown bound

[mpolacek at gcc dot gnu.org]

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

Bug 69531 Summary: Implement CWG 1307; Differently bounded array parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69531

   What|Removed |Added

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

[Bug c++/69531] Implement CWG 1307; Differently bounded array parameters

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Implemented for GCC 10.

[Bug c++/88128] G++ should implement CWG 330

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Wed Oct  9 20:58:00 2019
New Revision: 276771

URL: https://gcc.gnu.org/viewcvs?rev=276771=gcc=rev
Log:
Implement C++20 P0388R4, DR 1307, and DR 330.

This patch implements P0388R4, Permit conversions to arrays of unknown bound,
.  CWG 393 allowed references to arrays of unknown
bound and this C++20 feature allows conversions like

  void f(int(&)[]);
  int arr[1];

  void g() { f(arr); }
  int()[] = arr;

The proposal seemed fairly straightforward but it turned out to be quite
shifty.  I found out that I needed to implement DR 2352 (done), and also
DR 1307 (done in this patch).  The latter DR added wording for
list-initialization ranking of references to arrays which this proposal
extends.  DR 330 was also implemented in this patch.

PR c++/91364 - P0388R4: Permit conversions to arrays of unknown bound.
PR c++/69531 - DR 1307: Differently bounded array parameters.
PR c++/88128 - DR 330: Qual convs and pointers to arrays of pointers.
* call.c (build_array_conv): Build ck_identity at the beginning
of the conversion.
(standard_conversion): Pass bounds_none to comp_ptr_ttypes_const.
(maybe_warn_array_conv): New.
(convert_like_real): Call it.  Add an error message about converting
from arrays of unknown bounds.
(conv_get_original_expr): New.
(nelts_initialized_by_list_init): New.
(conv_binds_to_array_of_unknown_bound): New.
(compare_ics): Implement list-initialization ranking based on
array sizes, as specified in DR 1307 and P0388R.
* cp-tree.h (comp_ptr_ttypes_const): Adjust declaration.
(compare_bounds_t): New enum.
* typeck.c (comp_array_types): New bool and compare_bounds_t
parameters.  Use them.
(structural_comptypes): Adjust the call to comp_array_types.
(similar_type_p): Handle ARRAY_TYPE.
(build_const_cast_1): Pass bounds_none to comp_ptr_ttypes_const.
(comp_ptr_ttypes_real): Don't check cv-quals of ARRAY_TYPEs.  Use
comp_array_types to compare array types.  Look through arrays as per
DR 330.
(comp_ptr_ttypes_const): Use comp_array_types to compare array types.
Look through arrays as per DR 330.

* g++.dg/conversion/qual1.C: New test.
* g++.dg/conversion/qual2.C: New test.
* g++.dg/conversion/qual3.C: New test.
* g++.dg/conversion/ref2.C: New test.
* g++.dg/conversion/ref3.C: New test.
* g++.dg/cpp0x/initlist-array3.C: Remove dg-error.
* g++.dg/cpp0x/initlist-array7.C: New test.
* g++.dg/cpp0x/initlist-array8.C: New test.
* g++.dg/cpp2a/array-conv1.C: New test.
* g++.dg/cpp2a/array-conv10.C: New test.
* g++.dg/cpp2a/array-conv11.C: New test.
* g++.dg/cpp2a/array-conv12.C: New test.
* g++.dg/cpp2a/array-conv13.C: New test.
* g++.dg/cpp2a/array-conv14.C: New test.
* g++.dg/cpp2a/array-conv15.C: New test.
* g++.dg/cpp2a/array-conv16.C: New test.
* g++.dg/cpp2a/array-conv17.C: New test.
* g++.dg/cpp2a/array-conv2.C: New test.
* g++.dg/cpp2a/array-conv3.C: New test.
* g++.dg/cpp2a/array-conv4.C: New test.
* g++.dg/cpp2a/array-conv5.C: New test.
* g++.dg/cpp2a/array-conv6.C: New test.
* g++.dg/cpp2a/array-conv7.C: New test.
* g++.dg/cpp2a/array-conv8.C: New test.
* g++.dg/cpp2a/array-conv9.C: New test.
* g++.old-deja/g++.bugs/900321_01.C: Adjust dg-error.

* testsuite/23_containers/span/lwg3255.cc: Adjust test to match the
post-P0388R4 behavior.


Added:
trunk/gcc/testsuite/g++.dg/conversion/qual1.C
trunk/gcc/testsuite/g++.dg/conversion/qual2.C
trunk/gcc/testsuite/g++.dg/conversion/qual3.C
trunk/gcc/testsuite/g++.dg/conversion/ref2.C
trunk/gcc/testsuite/g++.dg/conversion/ref3.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-array7.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-array8.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv1.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv10.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv11.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv12.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv13.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv14.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv15.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv16.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv17.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv2.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv3.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv4.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv5.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv6.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv7.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv8.C

[Bug c++/91364] Implement P0388R4: Permit conversions to arrays of unknown bound

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Wed Oct  9 20:58:00 2019
New Revision: 276771

URL: https://gcc.gnu.org/viewcvs?rev=276771=gcc=rev
Log:
Implement C++20 P0388R4, DR 1307, and DR 330.

This patch implements P0388R4, Permit conversions to arrays of unknown bound,
.  CWG 393 allowed references to arrays of unknown
bound and this C++20 feature allows conversions like

  void f(int(&)[]);
  int arr[1];

  void g() { f(arr); }
  int()[] = arr;

The proposal seemed fairly straightforward but it turned out to be quite
shifty.  I found out that I needed to implement DR 2352 (done), and also
DR 1307 (done in this patch).  The latter DR added wording for
list-initialization ranking of references to arrays which this proposal
extends.  DR 330 was also implemented in this patch.

PR c++/91364 - P0388R4: Permit conversions to arrays of unknown bound.
PR c++/69531 - DR 1307: Differently bounded array parameters.
PR c++/88128 - DR 330: Qual convs and pointers to arrays of pointers.
* call.c (build_array_conv): Build ck_identity at the beginning
of the conversion.
(standard_conversion): Pass bounds_none to comp_ptr_ttypes_const.
(maybe_warn_array_conv): New.
(convert_like_real): Call it.  Add an error message about converting
from arrays of unknown bounds.
(conv_get_original_expr): New.
(nelts_initialized_by_list_init): New.
(conv_binds_to_array_of_unknown_bound): New.
(compare_ics): Implement list-initialization ranking based on
array sizes, as specified in DR 1307 and P0388R.
* cp-tree.h (comp_ptr_ttypes_const): Adjust declaration.
(compare_bounds_t): New enum.
* typeck.c (comp_array_types): New bool and compare_bounds_t
parameters.  Use them.
(structural_comptypes): Adjust the call to comp_array_types.
(similar_type_p): Handle ARRAY_TYPE.
(build_const_cast_1): Pass bounds_none to comp_ptr_ttypes_const.
(comp_ptr_ttypes_real): Don't check cv-quals of ARRAY_TYPEs.  Use
comp_array_types to compare array types.  Look through arrays as per
DR 330.
(comp_ptr_ttypes_const): Use comp_array_types to compare array types.
Look through arrays as per DR 330.

* g++.dg/conversion/qual1.C: New test.
* g++.dg/conversion/qual2.C: New test.
* g++.dg/conversion/qual3.C: New test.
* g++.dg/conversion/ref2.C: New test.
* g++.dg/conversion/ref3.C: New test.
* g++.dg/cpp0x/initlist-array3.C: Remove dg-error.
* g++.dg/cpp0x/initlist-array7.C: New test.
* g++.dg/cpp0x/initlist-array8.C: New test.
* g++.dg/cpp2a/array-conv1.C: New test.
* g++.dg/cpp2a/array-conv10.C: New test.
* g++.dg/cpp2a/array-conv11.C: New test.
* g++.dg/cpp2a/array-conv12.C: New test.
* g++.dg/cpp2a/array-conv13.C: New test.
* g++.dg/cpp2a/array-conv14.C: New test.
* g++.dg/cpp2a/array-conv15.C: New test.
* g++.dg/cpp2a/array-conv16.C: New test.
* g++.dg/cpp2a/array-conv17.C: New test.
* g++.dg/cpp2a/array-conv2.C: New test.
* g++.dg/cpp2a/array-conv3.C: New test.
* g++.dg/cpp2a/array-conv4.C: New test.
* g++.dg/cpp2a/array-conv5.C: New test.
* g++.dg/cpp2a/array-conv6.C: New test.
* g++.dg/cpp2a/array-conv7.C: New test.
* g++.dg/cpp2a/array-conv8.C: New test.
* g++.dg/cpp2a/array-conv9.C: New test.
* g++.old-deja/g++.bugs/900321_01.C: Adjust dg-error.

* testsuite/23_containers/span/lwg3255.cc: Adjust test to match the
post-P0388R4 behavior.


Added:
trunk/gcc/testsuite/g++.dg/conversion/qual1.C
trunk/gcc/testsuite/g++.dg/conversion/qual2.C
trunk/gcc/testsuite/g++.dg/conversion/qual3.C
trunk/gcc/testsuite/g++.dg/conversion/ref2.C
trunk/gcc/testsuite/g++.dg/conversion/ref3.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-array7.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-array8.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv1.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv10.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv11.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv12.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv13.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv14.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv15.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv16.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv17.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv2.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv3.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv4.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv5.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv6.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv7.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv8.C

[Bug c++/69531] Implement CWG 1307; Differently bounded array parameters

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Oct  9 20:58:00 2019
New Revision: 276771

URL: https://gcc.gnu.org/viewcvs?rev=276771=gcc=rev
Log:
Implement C++20 P0388R4, DR 1307, and DR 330.

This patch implements P0388R4, Permit conversions to arrays of unknown bound,
.  CWG 393 allowed references to arrays of unknown
bound and this C++20 feature allows conversions like

  void f(int(&)[]);
  int arr[1];

  void g() { f(arr); }
  int()[] = arr;

The proposal seemed fairly straightforward but it turned out to be quite
shifty.  I found out that I needed to implement DR 2352 (done), and also
DR 1307 (done in this patch).  The latter DR added wording for
list-initialization ranking of references to arrays which this proposal
extends.  DR 330 was also implemented in this patch.

PR c++/91364 - P0388R4: Permit conversions to arrays of unknown bound.
PR c++/69531 - DR 1307: Differently bounded array parameters.
PR c++/88128 - DR 330: Qual convs and pointers to arrays of pointers.
* call.c (build_array_conv): Build ck_identity at the beginning
of the conversion.
(standard_conversion): Pass bounds_none to comp_ptr_ttypes_const.
(maybe_warn_array_conv): New.
(convert_like_real): Call it.  Add an error message about converting
from arrays of unknown bounds.
(conv_get_original_expr): New.
(nelts_initialized_by_list_init): New.
(conv_binds_to_array_of_unknown_bound): New.
(compare_ics): Implement list-initialization ranking based on
array sizes, as specified in DR 1307 and P0388R.
* cp-tree.h (comp_ptr_ttypes_const): Adjust declaration.
(compare_bounds_t): New enum.
* typeck.c (comp_array_types): New bool and compare_bounds_t
parameters.  Use them.
(structural_comptypes): Adjust the call to comp_array_types.
(similar_type_p): Handle ARRAY_TYPE.
(build_const_cast_1): Pass bounds_none to comp_ptr_ttypes_const.
(comp_ptr_ttypes_real): Don't check cv-quals of ARRAY_TYPEs.  Use
comp_array_types to compare array types.  Look through arrays as per
DR 330.
(comp_ptr_ttypes_const): Use comp_array_types to compare array types.
Look through arrays as per DR 330.

* g++.dg/conversion/qual1.C: New test.
* g++.dg/conversion/qual2.C: New test.
* g++.dg/conversion/qual3.C: New test.
* g++.dg/conversion/ref2.C: New test.
* g++.dg/conversion/ref3.C: New test.
* g++.dg/cpp0x/initlist-array3.C: Remove dg-error.
* g++.dg/cpp0x/initlist-array7.C: New test.
* g++.dg/cpp0x/initlist-array8.C: New test.
* g++.dg/cpp2a/array-conv1.C: New test.
* g++.dg/cpp2a/array-conv10.C: New test.
* g++.dg/cpp2a/array-conv11.C: New test.
* g++.dg/cpp2a/array-conv12.C: New test.
* g++.dg/cpp2a/array-conv13.C: New test.
* g++.dg/cpp2a/array-conv14.C: New test.
* g++.dg/cpp2a/array-conv15.C: New test.
* g++.dg/cpp2a/array-conv16.C: New test.
* g++.dg/cpp2a/array-conv17.C: New test.
* g++.dg/cpp2a/array-conv2.C: New test.
* g++.dg/cpp2a/array-conv3.C: New test.
* g++.dg/cpp2a/array-conv4.C: New test.
* g++.dg/cpp2a/array-conv5.C: New test.
* g++.dg/cpp2a/array-conv6.C: New test.
* g++.dg/cpp2a/array-conv7.C: New test.
* g++.dg/cpp2a/array-conv8.C: New test.
* g++.dg/cpp2a/array-conv9.C: New test.
* g++.old-deja/g++.bugs/900321_01.C: Adjust dg-error.

* testsuite/23_containers/span/lwg3255.cc: Adjust test to match the
post-P0388R4 behavior.


Added:
trunk/gcc/testsuite/g++.dg/conversion/qual1.C
trunk/gcc/testsuite/g++.dg/conversion/qual2.C
trunk/gcc/testsuite/g++.dg/conversion/qual3.C
trunk/gcc/testsuite/g++.dg/conversion/ref2.C
trunk/gcc/testsuite/g++.dg/conversion/ref3.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-array7.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-array8.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv1.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv10.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv11.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv12.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv13.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv14.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv15.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv16.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv17.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv2.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv3.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv4.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv5.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv6.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv7.C
trunk/gcc/testsuite/g++.dg/cpp2a/array-conv8.C

[Bug tree-optimization/92039] New: [10 Regression] Spurious -Warray-bounds warnings building 32-bit glibc

[jsm28 at gcc dot gnu.org]

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

Bug ID: 92039
   Summary: [10 Regression] Spurious -Warray-bounds warnings
building 32-bit glibc
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47010
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47010=edit
Preprocessed source

The commit

r276645 | rguenth | 2019-10-07 07:53:45 + (Mon, 07 Oct 2019) | 20 lines

2019-10-07  Richard Biener  

PR tree-optimization/91975
* tree-ssa-loop-ivcanon.c (constant_after_peeling): Consistently
handle invariants.

introduced spurious -Warray-bounds warnings that break the glibc build for
certain 32-bit configurations (i686 and 32-bit powerpc and s390). I've attached
a testcase; compile with -m32 -O2 -Wall with an x86_64 compiler and you get:

In file included from ../sysdeps/ieee754/float128/strtof128_l.c:48,
 from ../sysdeps/ieee754/float128/wcstof128_l.c:27:
../stdlib/strtod_l.c: In function 'wcstof128_l_internal':
../stdlib/strtod_l.c:1676:22: warning: array subscript -1 is below array bounds
of 'mp_limb_t[4]' {aka 'long unsigned int[4]'} [-Warray-bounds]
In file included from ../sysdeps/ieee754/float128/strtof128_l.c:48,
 from ../sysdeps/ieee754/float128/wcstof128_l.c:27:
../stdlib/strtod_l.c:523:13: note: while referencing 'retval'

(Note the glibc build has been broken for other reasons lately; this issue was
bisected to that commit using the attached .i file rather than based on when
the glibc build worked or didn't work.)

The relevant code is:

# 1675 "../stdlib/strtod_l.c"
for (i = (((113) + ((32) - 1)) / (32)) - 1; i >= empty; --i)
   retval[i] = retval[i - empty];

from which it should be clear that, as i >= empty, this warning is bogus. (i is
int and empty is mp_size_t which is long int.)

[Bug other/91879] --with-build-time-tools doesn't work as expected

[joseph at codesourcery dot com]

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

--- Comment #37 from joseph at codesourcery dot com  ---
On Wed, 9 Oct 2019, stsp at users dot sourceforge.net wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
> 
> --- Comment #36 from Stas Sergeev  ---
> (In reply to jos...@codesourcery.com from comment #35)
> > what you want.  I'm familiar with many of the details through having 
> > written multiple such build systems myself.
> 
> But even you do make the wrong expectations.
> Most of your suggestions (which are very reasonable by
> themselves) do not work or require additional tweaks.
> configure reacts inadequately on them.

They're essentially hints about approaches to look at - not full recipes, 
because that ends up in writing a whole build system.

> Does --with-sysroot disable prefix, or prefix should
> be set to '/' explicitly? Or to something else?

A toolchain always has a prefix, as configured using --prefix=.  
--with-sysroot sets a sysroot path (normally under the prefix, but that 
isn't required).  In the case where the target has an OS with a root 
filesystem that can have libraries and headers installed for native 
compilation, the --with-sysroot directory is expected to be laid out like 
the relevant parts of the target's root filesystem.

> If I naively do
> --with-build-sysroot=$DESTDIR --with-sysroot=/
> why this won't work? I suppose there will be some
> differences in a directory layout, like no $target
> dir, but otherwise it can work?

The build sysroot directory needs to contain the target libraries.  For 
example, include/ or usr/include/ (depending on how the toolchain is 
configured) under that directory should contain headers, lib/ or usr/lib/ 
should contain .a and .so files.  These need to be files for the target.

> You suggest --with-sysroot=$prefix/$target but I
> don't understand why is so, as normally I have
> (1) $prefix/bin/$target-gcc
> and
> (2) $prefix/$target/bin/gcc
> If I set --with-sysroot=$prefix/$target then I
> can get (2), but how to get (1)?

I advise ignoring the files in $prefix/$target/bin/, which are nothing to 
do with the sysroot (they are host binaries).  They aren't intended to be 
run directly; they're an implementation detail.  Some, such as the 
binutils ones ($prefix/$target/bin/as etc.) may be run automatically by 
GCC.  Others, such as $prefix/$target/bin/gcc, may be of little use 
(unless the compiler ends up using them when it re-execs the compiler 
driver when linking, which can happen in certain cases - if it does, it 
sets environment variables to allow it to work properly).

> I think this is an rtfm point, is this sysroot trick documented 
> anywhere?

I think it falls between the cracks of the different toolchain components.  
Each component documents how to configure and build that component, in 
isolation.  But this trick is part of how you build a whole toolchain 
rather than part of how one component is built, so no one component is the 
right place to document it.

Existing build systems such as crosstool-ng are a good place to look for 
such tricks.  However, many such build systems are full of tricks that 
once were necessary but haven't been for many years, or approaches that 
still work but have long been obsolescent.  When writing 
build-many-glibcs.py I tried to use the preferred current approach to 
everything and avoid those obsolescent tricks, but that only shows you one 
case of building toolchains for a glibc target (and without the relocation 
issues being discussed in this bug, as those weren't relevant for that 
script).

[Bug c/87488] hyperlink filenames in diagnostics

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-09
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #8 from David Malcolm  ---
I'm working on an implementation of this, providing URLs for option
documentation for the [-Woption-name] suffixes to diagnostics.

[Bug c++/57025] Solaris g++ defines __STDC_VERSION__=199901L

[alan.coopersmith at oracle dot com]

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

Alan Coopersmith  changed:

   What|Removed |Added

 CC||alan.coopersmith at oracle dot 
com
   ||,
   ||ro at CeBiTec dot 
Uni-Bielefeld.DE

--- Comment #7 from Alan Coopersmith  ---
This seems to go back to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a6905708d86d6c2d8560168ac5accb816a2038c8
and was probably to deal with the bit of the Solaris system headers in
various releases that throws an error if you try to define _XOPEN_SOURCE
to 600 or 700 and didn't have a __STDC_VERSION__ matching C99 defined.

[Bug c++/92032] DR 1601 - Promotion of enumeration with fixed underlying type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Resolved in GCC 10.

[Bug c++/92032] DR 1601 - Promotion of enumeration with fixed underlying type

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Wed Oct  9 17:49:26 2019
New Revision: 276766

URL: https://gcc.gnu.org/viewcvs?rev=276766=gcc=rev
Log:
PR c++/92032 - DR 1601: Promotion of enum with fixed underlying type.

I've been messing with compare_ics recently and noticed that we don't
implement CWG 1601, which should be fairly easy.  Thus this patch.

The motivating example is 
  enum E : char { e };
  void f(char);
  void f(int);
  void g() {
f(e);
  }
where the call to f was ambiguous but we should choose f(char).

Currently we give f(int) cr_promotion in standard_conversion, while
f(char) remains cr_std, which is worse than cr_promotion.  So I thought
I'd give it cr_promotion also and then add a tiebreaker to compare_ics.

* call.c (standard_conversion): When converting an enumeration with
a fixed underlying type to the underlying type, give it the
cr_promotion
rank.
(compare_ics): Implement a tiebreaker as per CWG 1601.

* g++.dg/cpp0x/scoped_enum10.C: New test.
* g++.dg/cpp0x/scoped_enum11.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/cpp0x/scoped_enum10.C
trunk/gcc/testsuite/g++.dg/cpp0x/scoped_enum11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/91457] FAIL: g++.dg/warn/Warray-bounds-4.C -std=gnu++98 (test for warnings, line 25)

[msebor at gcc dot gnu.org]

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

--- Comment #16 from Martin Sebor  ---
The warning code hasn't changed.  What's different is that the MEM_REF that
-Warray-bounds doesn't handle isn't in the IL anymore.  The
hppa2.0w-hp-hpux11.11 IL for the test case in comment #6 looks just like the
x86_64 IL and so the same warning is issued for both (see below).  I don't know
what commit is behind the change.

$ cat pr91457.C && /build/hppa2.0w-hp-hpux11.11/gcc-svn/gcc/xgcc -B
/build/hppa2.0w-hp-hpux11.11/gcc-svn/gcc -S -O2 -Wall
-fdump-tree-dom3=/dev/stdout pr91457.C
struct A
{
  char n, a[0];

  A () { a[0] = 0; }
};

void f (struct A*);

void g (void)
{
  struct A a;
  f ();
}
pr91457.C: In function 'void g()':
pr91457.C:5:13: warning: array subscript 0 is above array bounds of 'char [0]'
[-Warray-bounds]
5 |   A () { a[0] = 0; }
  |  ~~~^
pr91457.C:3:11: note: while referencing 'A::a'
3 |   char n, a[0];
  |   ^

;; Function g (_Z1gv, funcdef_no=3, decl_uid=1937, cgraph_uid=4,
symbol_order=3)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }
g ()
{
  struct A a;

   [local count: 1073741824]:
  a ={v} {CLOBBER};
  a.a[0] = 0;
  f ();
  a ={v} {CLOBBER};
  return;

}

[Bug target/92038] New: Extremely inefficient x86_64 code for trivally copyable types passed in registers.

[maxim.yegorushkin at gmail dot com]

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

Bug ID: 92038
   Summary: Extremely inefficient x86_64 code for trivally
copyable types passed in registers.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maxim.yegorushkin at gmail dot com
  Target Milestone: ---

The following code:

#include 
void f(std::variant);
void g() { f({}); }

When compiled with `g++-9.2 -std=gnu++17 -O3 -march=skylake` generates the
following assembly:

g():
mov DWORD PTR [rsp-16], 0
mov BYTE PTR [rsp-12], 0
mov rdi, QWORD PTR [rsp-16]
jmp f(std::variant)

Which is rather poor: unnecessary memory stores; dependency of rdi on the value
of 3 bytes of padding at [rsp-11], [rsp-10], [rsp-9] which are unset, which may
prevent store-to-load forwarding.

`clang++-8.0 -std=gnu++17 -O3 -march=skylake` generates the expected assembly:

g():
xor edi, edi
jmp f(std::variant)

[Bug libstdc++/91057] Data race in locale(const locale&, Facet*) constructor

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Wed Oct  9 15:59:56 2019
New Revision: 276762

URL: https://gcc.gnu.org/viewcvs?rev=276762=gcc=rev
Log:
PR libstdc++/91057 set locale::id::_M_index atomically

If two threads see _M_index==0 concurrently they will both try to set
it, potentially storing the facet at two different indices in the array.

Either set the _M_index data member using an atomic compare-exchange
operation or while holding a mutex.

Also move the LONG_DOUBLE_COMPAT code into a separate function to remove
the visual noise it creates.

PR libstdc++/91057
* src/c++98/locale.cc (locale::id::_M_id()) [__GTHREADS]: Use atomic
compare-exchange or double-checked lock to ensure only one thread sets
the _M_index variable.
[_GLIBCXX_LONG_DOUBLE_COMPAT]: Call find_ldbl_sync_facet to detect
facets that share another facet's ID.
[_GLIBCXX_LONG_DOUBLE_COMPAT] (find_ldbl_sync_facet): New function.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++98/locale.cc

[Bug c++/92034] extern template declarations cannot have internal linkage (unnamed namespace)

[alisdairm at me dot com]

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

--- Comment #4 from Alisdair Meredith  ---
(In reply to Jonathan Wakely from comment #3)
> I'm not sure if a diagnostic is required. The standard doesn't specifically
> say it's ill-formed to do this. By my reading it's undefined, and so
> silently accepting it is a conforming (but unhelpful) implementation.

My reading of [intro.compliance]p1 is that this would be a diagnosable error,
but navigating core wording is hard if you do not know all of the exact places
that contribute, and could easily have missed a clarification?

[Bug middle-end/92016] [10 Regression] excess errors in Wstringop-overflow-17.c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-09
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[iii at linux dot ibm.com]

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

Ilya Leoshkevich  changed:

   What|Removed |Added

 CC||iii at linux dot ibm.com

--- Comment #2 from Ilya Leoshkevich  ---
I will have a look at this and try to adjust the CLEANUP_THREADING code.

[Bug gcov-profile/91971] Profile directory concatenated with object file path

[qinzhao at gcc dot gnu.org]

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

--- Comment #1 from qinzhao at gcc dot gnu.org ---
the following simple patch will fix this issue:

$ git diff coverage.c
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 0d5138f..a80337e 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1229,6 +1229,11 @@ coverage_init (const char *filename)
   else
profile_data_prefix = getpwd ();
 }
+  else
+{
+  filename = mangle_path (filename);
+  len = strlen (filename);
+}

   if (profile_data_prefix)
 prefix_len = strlen (profile_data_prefix);

[Bug target/92030] Wrong asm code for aliases on MIPS.

[anikulin at dlink dot ru]

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

Alexander Nikulin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Alexander Nikulin  ---
resolved.

[Bug c++/88128] G++ should implement CWG 330

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
I think I have a patch; e.g. this now compiles:

double *const (*d)[3];
double const *const (*e)[3] = d;
int *(*f)[3];
const int *const (*g)[3] = f;

int main()
{
 double *array2D[2][3];

 double   *   (*array2DPtr1)[3] = array2D; // Legal
 double   * const (*array2DPtr2)[3] = array2DPtr1; // Legal
 double const * const (*array2DPtr3)[3] = array2DPtr2; // Illegal
}

[Bug target/92030] Wrong asm code for aliases on MIPS.

[anikulin at dlink dot ru]

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

--- Comment #4 from Alexander Nikulin  ---
(In reply to Alexander Monakov from comment #3)
> The alias attribute usually works fine with declarations of static variables.
> 
> So, have you tried
> 
> static struct memtype MTYPE_##name[1] __attribute__((alias("_mt_" #name)));
> 
> (i.e. with 'static' rather that 'extern')?

I was sure I did! And this reported smth like 'already defined' or similar.

Different combinations of attributes were tried and likely I lost this obvious
one.

Thanks a lot, it works.

So the decision is found.

If the .equiv behaviour is not buggy really, I guess the case may be closed.
Should I change its status myself or wait for an admin's verdict?


Thanks again.

[Bug middle-end/92037] [10 Regression] LTO bootstrap broken in selftests

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Note my stage1 compiler was built with gcc 9.2.1 (r274748) and
STAGE1_CFLAGS=-O2
trying with -O0 stage1 now.

[Bug middle-end/92037] [10 Regression] LTO bootstrap broken in selftests

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Target||x86_64-*-*
Version|9.2.1   |10.0
   Target Milestone|--- |10.0

[Bug middle-end/92037] New: [10 Regression] LTO bootstrap broken in selftests

[rguenth at gcc dot gnu.org]

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

Bug ID: 92037
   Summary: [10 Regression] LTO bootstrap broken in selftests
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

In stage2:

/abuild/rguenther/obj2/./gcc/xgcc -B/abuild/rguenther/obj2/./gcc/ -xc -nostdinc
/dev/null -S -o /dev/null
-fself-test=/space/rguenther/src/svn/trunk-bisect/gcc/testsuite/selftests
cc1: internal compiler error: Segmentation fault
0x11bd0df crash_signal
/space/rguenther/src/svn/trunk-bisect/gcc/toplev.c:326
0x15b099f symbol_table::register_symbol(symtab_node*)
/space/rguenther/src/svn/trunk-bisect/gcc/cgraph.h:2658
0x15b099f symtab_node::register_symbol()
/space/rguenther/src/svn/trunk-bisect/gcc/symtab.c:377
0x15b0afc cgraph_node::create(tree_node*)
/space/rguenther/src/svn/trunk-bisect/gcc/cgraph.c:523
0x15b0d1a cgraph_node::get_create(tree_node*)
/space/rguenther/src/svn/trunk-bisect/gcc/cgraph.c:545
0x156f76b test_capture_of_dump_calls
/space/rguenther/src/svn/trunk-bisect/gcc/dumpfile.c:2236
0xaae967 selftest::run_tests()
/space/rguenther/src/svn/trunk-bisect/gcc/selftest-run-tests.c:62
0x11bd169 toplev::run_self_tests()
/space/rguenther/src/svn/trunk-bisect/gcc/toplev.c:2230
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [/space/rguenther/src/svn/trunk-bisect/gcc/c/Make-lang.in:124:
s-selftest-c] Error 1

[Bug target/92030] Wrong asm code for aliases on MIPS.

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
The alias attribute usually works fine with declarations of static variables.

So, have you tried

static struct memtype MTYPE_##name[1] __attribute__((alias("_mt_" #name)));

(i.e. with 'static' rather that 'extern')?

[Bug libstdc++/91057] Data race in locale(const locale&, Facet*) constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |10.0

[Bug libstdc++/67903] std::locale compatibility between gcc4.9 and gcc5.1

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Yucheng Low from comment #5)
>  - We compile as a shared library to be imported into Python as part of a
> python 
> module. 
>  - We want to use C++11 features yet we want to be able to run on 
> relatively old Linux distributions, hence we must package our own libstdc++.
>  - However, there are other Python modules which are source distributions and
>  compile on the system itself hence depends on the system's existing
> libtsdc++.
>  - Since the system will only load 1 instance of libstdc++ at a time, we
> can't
>  merely distribute libstdc++.so. Doing so will mean whether we load correctly
>  or not will depend on import ordering.
>  - Therefore we must static link libstdc++ into our shared library.
>  - As a result there are actually 2 instances of libstdc++ symbols loaded
> into 
>  Python (This ought to work since Python uses RTLD_LOCAL)

I think what you're doing is unsupported and unlikely to work like this.

You should look into using a devtoolset compiler to avoid dependencies on
symbols from the newer libstdc++.

You might be able to do it yourself with a carefully crafted linker script, but
that work has already been done when creating devtoolset.

> Key Issue
> -
> Now, the key issue is that all [facet]::id are a UNIQUE symbol which crosses 
> RTLD_LOCAL boundaries, EXCEPT for ctype::id, codecvt::id, 
> ctype::id, and codecvt::id which are WEAK.

That is surprising to me. I would expect them all to use STB_GNU_UNIQUE.

> Solution
> 
> It might be easy to solve this problem for libstdc++'s going forward. Make
> all
> the [facet]::id variables WEAK. 

I don't think that's what we want. All globals should be unique.

[Bug libstdc++/78552] std::locale::classic() Needless Race

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk. I might backport it to release branches later, but closing as
FIXED for now.

[Bug libstdc++/78552] std::locale::classic() Needless Race

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Wed Oct  9 12:55:39 2019
New Revision: 276758

URL: https://gcc.gnu.org/viewcvs?rev=276758=gcc=rev
Log:
PR libstdc++/78552 only construct std::locale for C locale once

PR libstdc++/78552
* src/c++98/locale_init.cc (locale::classic()): Do not construct a new
locale object for every call.
(locale::_S_initialize_once()): Construct C locale here.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++98/locale_init.cc

[Bug libstdc++/78552] std::locale::classic() Needless Race

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
I have a patch for this, but helgrind and drd still get upset because they
don't understand pthread_once.

[Bug lto/91576] [10 Regression] error: invalid conversion in gimple call since r272749

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #4 from David Binderman  ---
I am seeing something similar:

/usr/include/clang/AST/ExternalASTSource.h:400:6: error: invalid conversion in
gimple call
  400 |   T* get(ExternalASTSource *Source) const {
  |  ^~~
struct CXXBaseSpecifier *

int

_6 = _3 (Source, _5);
/usr/include/clang/AST/ExternalASTSource.h:400:6: internal compiler error:
'verify_gimple' failed
0x1010dfd verify_gimple_in_seq(gimple*)
../../trunk/gcc/tree-cfg.c:5079
0xd40ade gimplify_body(tree_node*, bool)
../../trunk/gcc/gimplify.c:14439
0xd40cc7 gimplify_function_tree(tree_node*)
../../trunk/gcc/gimplify.c:14529
0xba7c37 cgraph_node::analyze()
../../trunk/gcc/cgraphunit.c:667

[Bug c++/87820] Explicit user-defined casting inside a template class working in implicit conversion inside function template

[ExtComm.CODA at dlr dot de]

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

--- Comment #3 from ExtComm.CODA at dlr dot de ---
(In reply to Francisco Gallego Salido from comment #2)
> (In reply to ExtComm.CODA from comment #1)
> > clang and intel-compiler don't fail
> 
> And no, in clang and MSVC neither of the code snippets compile, which is
> what's supposed to happen.

 Sorry for my poor English. 'don't fail' in that context means: 'they do as
expected'

[Bug middle-end/92036] OpenACC 'firstprivate' clause: initial value

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed Oct  9 11:31:14 2019
New Revision: 276757

URL: https://gcc.gnu.org/viewcvs?rev=276757=gcc=rev
Log:
[PR92036] Add 'libgomp.oacc-c-c++-common/data-firstprivate-1.c'

libgomp/
PR middle-end/92036
* testsuite/libgomp.oacc-c-c++-common/data-firstprivate-1.c: New
file.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/data-firstprivate-1.c
Modified:
trunk/libgomp/ChangeLog

[Bug middle-end/92036] OpenACC 'firstprivate' clause: initial value

[tschwinge at gcc dot gnu.org]

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

--- Comment #3 from Thomas Schwinge  ---
If I quickly got that right, the current implementation is described in the
thread starting at  -- and
Nathan seems to have had a different idea of what the expected semantics are,
contrary to what I just described.  But in turn, my recent description seems to
match that Jakub expected back then.


Please do not yet work on any 'GOMP_MAP_FIRSTPRIVATE_INT' things, unless what
naturally falls out when (possibly) revising the implementation.  (Related to
that, I have some further pending changes related to our openacc-gcc-9-branch
commits for 'GOMP_MAP_FIRSTPRIVATE_INT', which is how I found this issue.)

[Bug middle-end/92036] OpenACC 'firstprivate' clause: initial value

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-09
   Assignee|unassigned at gcc dot gnu.org  |jules at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Thomas Schwinge  ---
Julian, please have a look: intention of the OpenACC specification vs. current
GCC implementation.  Probably a good idea to also cross-verify with another
OpenACC compiler.


(Why this is relevant right now: in openacc-gcc-9-branch, we have a few patches
related to 'firstprivate', but I think before considering these for GCC trunk,
we'll need to resolve (or reject, if invalid) this issue here.)

[Bug middle-end/92036] New: OpenACC 'firstprivate' clause: initial value

[tschwinge at gcc dot gnu.org]

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

Bug ID: 92036
   Summary: OpenACC 'firstprivate' clause: initial value
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---

I think our implementation of OpenACC 'firstprivate' clause (on the OpenACC
'parallel' construct) is wrong regarding where such a variable gets initialized
from if a device copy already exists.

What we currently seem to be doing, in case that the respective original
variable already has a device copy, is to initialize the 'firstprivate' copy
from the *device* copy, which potentially might have a different value. 
However, the OpenACC 2.0a specification in 2.5.10 "firstprivate clause" asks
that "the copy will be initialized with the value of that item *on the host*
when the 'parallel' construct is encountered" (emphasis mine), in other words
(my interpretation), initialized by the dynamic (current) value of the
*original* variable (specified in the 'firstprivate' clause) at the time the
OpenACC 'parallel' construct is encountered.

The current OpenACC 2.7 specification in 2.5.12. "firstprivate clause" asks
that "the copy will be initialized with the value of that item *on the local
thread* when a 'parallel' or 'serial' construct is encountered" (emphasis
mine).  The term "local thread" in 6. "Glossary" gets defined as "the host
thread [...] that executes an OpenACC directive or construct" (omitted the
variant "or the accelerator thread" as that's (a) still the same semantics, and
(b) not relevant as long as we're not implementing OpenACC nested parallelism).
 So, I read that as the same as the original OpenACC 2.0a.

This, per my current understanding, matches the semantics of the OpenMP
'firstprivate' clause.  (Jakub?)

I suppose this needs to be re-worked (at least) in the gimplifier?

Not sure if that's related, but as far as I understand, the OpenACC handling of
'OMP_CLAUSE_FIRSTPRIVATE' in 'gcc/omp-low.c' is rather different from the
OpenMP handling -- might that also be relevant to this issue here?

[Bug tree-optimization/92029] [10 Regression] 'libgomp.fortran/pr90779.f90' ICE for nvptx offloading

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Wed, 9 Oct 2019, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92029
> 
> --- Comment #4 from Jakub Jelinek  ---
> Just a general comment, what we need to ensure is that the tables contain the
> same variables in the same order between what we emit on the host and in LTO
> for the offloading targets.  It is fine if we are able to remove some variable
> as unused before the LTO streaming, as long as we manage to update whatever
> needs to be to ensure the tables are the same.  After the streaming, we can't
> remove anything mentioned in the tables.

OK, so ideally we'd compute the table contents at the time we stream
then, using IPA-REF info in case that is readily available.

[Bug tree-optimization/92029] [10 Regression] 'libgomp.fortran/pr90779.f90' ICE for nvptx offloading

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Just a general comment, what we need to ensure is that the tables contain the
same variables in the same order between what we emit on the host and in LTO
for the offloading targets.  It is fine if we are able to remove some variable
as unused before the LTO streaming, as long as we manage to update whatever
needs to be to ensure the tables are the same.  After the streaming, we can't
remove anything mentioned in the tables.

[Bug tree-optimization/92029] [10 Regression] 'libgomp.fortran/pr90779.f90' ICE for nvptx offloading

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
(In reply to Richard Biener from comment #2)
> another fix would be to _not_ stream it into the offload section in
> output_offload_tables if the variable was removed:
> 
> diff --git a/gcc/lto-cgraph.c b/gcc/lto-cgraph.c
…
> +  if (varpool_node::get ((*offload_vars)[i]))

At least that's not sufficient as it then fails at:

#0  0x0063b6e8 in vec::operator[]
(this=0x0, ix=0) at gcc-mainline/gcc/vec.h:859
859   gcc_checking_assert (ix < m_vecpfx.m_num);

Note the "this=0x0"; ix is 0.

Called via:
lto-streamer.h:1242| DEFINE_DECL_STREAM_FUNCS (VAR_DECL, var_decl)
lto-streamer.h:124 | if (varpool_node::get ((*offload_vars)[i]))
lto-cgraph.c:1781  |  lto_file_decl_data_get_var_decl (file_data, decl_index);
lto-common.c:2797  | input_offload_tables (!flag_ltrans);

lto_file_decl_data_get_var_decl uses:
  struct lto_in_decl_state *state = data->current_decl_state; \
   return (*state->streams[LTO_DECL_STREAM_## UPPER_NAME])[idx]; \
and we have "idx = 0" and:
 *file_data->current_decl_state
$8 = {streams = {0x0, 0x0, 0x773eb500, 0x0, 0x0, 0x0, 0x0}, fn_decl = 0x0,
compressed = true}

[Bug target/88918] [meta-bug] x86 intrinsic issues

[jakub at gcc dot gnu.org]

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

Bug 86444 Summary: [X86] Implementation of SSE comi/ucomi intrinsics does not 
match recent versions of icc, clang, or MSVC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86444

   What|Removed |Added

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

[Bug target/86444] [X86] Implementation of SSE comi/ucomi intrinsics does not match recent versions of icc, clang, or MSVC

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/88918] [meta-bug] x86 intrinsic issues

[jakub at gcc dot gnu.org]

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

Bug 89750 Summary: Wrong code for _mm_comi_round_ss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89750

   What|Removed |Added

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

[Bug target/89750] Wrong code for _mm_comi_round_ss

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
.

[Bug target/86444] [X86] Implementation of SSE comi/ucomi intrinsics does not match recent versions of icc, clang, or MSVC

[crazylht at gmail dot com]

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

--- Comment #4 from Hongtao.liu  ---
(In reply to Jakub Jelinek from comment #3)
> So fixed?

Fixed in gcc10.

[Bug target/89750] Wrong code for _mm_comi_round_ss

[crazylht at gmail dot com]

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

--- Comment #5 from Hongtao.liu  ---
(In reply to Jakub Jelinek from comment #4)
> So, fixed for 10+?

Yes.

[Bug tree-optimization/92029] [10 Regression] 'libgomp.fortran/pr90779.f90' ICE for nvptx offloading

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #2 from Richard Biener  ---
It means the variable is gone.  I guess it's too late to mark the variable as
force_output where it is currently done.  Maybe do it in
varpool_node::get_create
where we also push it to the offload_vars vector?  I'm not sure if at that
point the variable is used in the IL but only "meta-wise" thus another
fix would be to _not_ stream it into the offload section in
output_offload_tables
if the variable was removed:

diff --git a/gcc/lto-cgraph.c b/gcc/lto-cgraph.c
index 147975ba869..481b4a5b45c 100644
--- a/gcc/lto-cgraph.c
+++ b/gcc/lto-cgraph.c
@@ -1076,8 +1076,9 @@ output_offload_tables (void)
 {
   streamer_write_enum (ob->main_stream, LTO_symtab_tags,
   LTO_symtab_last_tag, LTO_symtab_variable);
-  lto_output_var_decl_index (ob->decl_state, ob->main_stream,
-(*offload_vars)[i]);
+  if (varpool_node::get ((*offload_vars)[i]))
+   lto_output_var_decl_index (ob->decl_state, ob->main_stream,
+  (*offload_vars)[i]);
 }

   streamer_write_uhwi_stream (ob->main_stream, 0);

I'm also curious why we need to populate offload_vars during varpool node
creation time rather than when streaming the offload portion.  IPA
references should allow to identify those that need streaming?

But that's a larger re-org.

That said, the change just exposed a latent issue - a variable being optimized
away between putting it into offload_vars and streaming out.

[Bug tree-optimization/92029] [10 Regression] 'libgomp.fortran/pr90779.f90' ICE for nvptx offloading

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
In particular, it happens for in nvptx-none/lto1 for:

 > initial
>


In symtab_node::get () – as called in "varpool_node::get
(var_decl)->force_output = 1;" - one has:
437 return decl->decl_with_vis.symtab_node;
and this returns NULL.

The core code Fortran code is (with: "integer :: v(4), i"):
  !$omp target map(from:v)
v(:) = (/ (i, i=1,4) /)
  !$omp end target

omplower dump has:

.omp_data_arr.6.v = 
#pragma omp target num_teams(1) thread_limit(0) map(from:v [len: 16])
[child fn: MAIN__._omp_fn.0 (.omp_data_arr.6, .omp_data_sizes.7,
.omp_data_kinds.8)]
  {
.omp_data_i = (const struct .omp_data_t.5 & restrict)
&.omp_data_arr.6;
{
  static integer(kind=4) A.0[4] = {1, 2, 3, 4};

  D.3933 = .omp_data_i->v;
  D.3934 = D.3933;
  D.3935 = MEM  [(c_char * {ref-all})];
  MEM  [(c_char * {ref-all})D.3934] = D.3935;
}
#pragma omp return
  }
.omp_data_arr.6 = {CLOBBER};


In the optimized dump for MAIN__._omp_fn.0, one has – with -O0:
integer(kind=4) A.0[4];
…
_3 = .omp_data_i_2(D)->v;
_4 = _3;
_5 = MEM  [(c_char * {ref-all})];
MEM  [(c_char * {ref-all})_4] = _5;

And with -Og (which ICEs):
   _3 = .omp_data_i_2(D)->v;
   MEM  [(c_char * {ref-all})_3] = 0x4000300020001;

[Bug c++/83730] Unnecessary generation of guard variables with -fno-threadsafe-statics

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
As I noted at https://gcc.gnu.org/ml/gcc-help/2019-10/msg00038.html the guard
variable is emitted, but appears to be unused when compiled with
-fno-threadsafe-statics.

[Bug c++/92034] extern template declarations cannot have internal linkage (unnamed namespace)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-09
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
I'm not sure if a diagnostic is required. The standard doesn't specifically say
it's ill-formed to do this. By my reading it's undefined, and so silently
accepting it is a conforming (but unhelpful) implementation.

Confirming as a diagnostic enhancement at least (and maybe accepts-invalid if
it's supposed to require a diagnostic).

[Bug c++/68957] Wrong overload resolution for unscoped enums with fixed underlying type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Roger Orr from comment #1)
> This is still open with gcc 9.0...looks like it's stalled?

No, it never even left the starting grid.

But it has now.

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

[Bug c++/92032] DR 1601 - Promotion of enumeration with fixed underlying type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from Jonathan Wakely  ---
*** Bug 68957 has been marked as a duplicate of this bug. ***

[Bug c++/90894] maybe_unused attribute is ignored on function parameters in explicitly instantiated templates

[TonyELewis at hotmail dot com]

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

Tony E Lewis  changed:

   What|Removed |Added

 CC||TonyELewis at hotmail dot com

--- Comment #1 from Tony E Lewis  ---
I've also just hit this issue. Good work on the clear, simple repro code Matt.

>From what I can see using Godbolt, this issue has now been fixed between 9.2
and the current trunk (10.0.0 20191008).

[Bug target/86040] [avr]: RAMPZ is not always cleared after loading __flashN data

[gjl at gcc dot gnu.org]

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

--- Comment #6 from Georg-Johann Lay  ---
Created attachment 47009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47009=edit
proposed patch

[Bug target/92030] Wrong asm code for aliases on MIPS.

[anikulin at dlink dot ru]

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

--- Comment #2 from Alexander Nikulin  ---
(In reply to Richard Biener from comment #1)
> You're doing it behind the back of the compiler - maybe use
> __attribute__((alias("abc1"))) instead?

Hi Richard,

yes, I did.

It declares global symbol 'abc2':

-
-#APP
-   .equiv abc2, abc1
-
+   .globl  abc2
+   abc2 = abc1
.rdata
.align  2
-

00411010 d abc1
00411010 D abc2
 ^

and it works with my snippet:
@abc1 = 0x411010, abc2 = 0x411010, @abc2 = 0x411010

But as I understood, the developers would like to have a static alias-symbol
exactly.

Building FRR with __attribute__((alias(...))):
extern struct memtype MTYPE_##name[1] __attribute__((alias("_mt_" #name)));

produces the expected:
.../grammar_sandbox.c:38: multiple definition of `MTYPE_CMD_TOKENS'
.../command_graph.c:29: first defined here


Am agreed that the .equiv trick may be treated as a hack, but I can not offer a
valid replacement. And it works fine on
x86_64: (Debian 8.2.0-16),
i686: (Debian 6.3.0-18+deb9u1),
very ancient xscale/armv5b: (gcc-4.4.3).

Now I have no aarch64 board to check a compiled binary, but I see LO calls for
abc2 in the generated asm.


If this is not a compiler bug but wrong coding approach, could you please offer
the decision which provides "static" aliases?

Thanks!

[Bug target/86444] [X86] Implementation of SSE comi/ucomi intrinsics does not match recent versions of icc, clang, or MSVC

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
So fixed?

[Bug target/89750] Wrong code for _mm_comi_round_ss

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
So, fixed for 10+?

[Bug testsuite/91884] libgomp testsuite: (not) using a specific driver for C++, Fortran

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
See patches at:
https://gcc.gnu.org/ml/gcc-patches/2019-10/threads.html#00559

- First one:
* is the simple patch which got "in" (r276754) - and adds "-lquadmath"
conditionally.
* The "PS:" shows the hurdles to overcome if one wants to use "gfortran" or
  "g++" with an in-build-dir test run.

- Second one is a cleanup patch + and it uses {GFORTRAN,GXX}_UNDER_TEST, if
set.
  But that's only set with an installed-compiler run (cf. above).

Unless someone prefers the second patch - or likes, e.g., to modify
gcc/testcases/lib/*.dg's _init() to actually work when called from a
library path.
I regard this as FIXED as it handles the original issue: a missing -lquadmath.

[Bug target/91066] GCC does not provide XOP functions through

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
In immintrin.h i stands for Intel, so for non-Intel ISAs it is correct they
aren't included.  These builtins are in xopintrin.h which is included from
x86intrin.h, which is the header that you should include.  That is the standard
in other compilers too.

[Bug testsuite/91884] libgomp testsuite: (not) using a specific driver for C++, Fortran

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
Author: burnus
Date: Wed Oct  9 08:37:44 2019
New Revision: 276754

URL: https://gcc.gnu.org/viewcvs?rev=276754=gcc=rev
Log:
2019-10-09  Tobias Burnus  

PR testsuite/91884
* testsuite/libgomp.fortran/fortran.exp: Conditionally
add -lquadmath.
* testsuite/libgomp.oacc-fortran/fortran.exp: Ditto.


Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.fortran/fortran.exp
trunk/libgomp/testsuite/libgomp.oacc-fortran/fortran.exp

[Bug libgomp/92028] OpenACC 'host_data' execution test regressions with nvptx offloading

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Oct  9 07:33:02 2019
New Revision: 276753

URL: https://gcc.gnu.org/viewcvs?rev=276753=gcc=rev
Log:
PR libgomp/92028
* target.c (gomp_map_vars_internal): Readd the previous
GOMP_MAP_USE_DEVICE_PTR handling code in the first loop,
though do that just in the !not_found_cnt case.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/target.c

[Bug c++/92034] extern template declarations cannot have internal linkage (unnamed namespace)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #2 from Richard Biener  ---
The question is whether a diagnostic is required or not.  Having one would of
course be good (maybe this "feature" can be used to elide instantiation of
unneeded but eventually auto-instantiated pieces?)

[Bug target/92030] Wrong asm code for aliases on MIPS.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||mips

--- Comment #1 from Richard Biener  ---
You're doing it behind the back of the compiler - maybe use
__attribute__((alias("abc1"))) instead?