[Bug middle-end/64711] Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations and memmov

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #8 from rguenther at suse dot de  ---
On Thu, 12 Nov 2020, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711
> 
> --- Comment #7 from Eric Botcazou  ---
> > The issue with clearing nothrow is that those pesky builtins have
> > that "sticky" while the per-stmt flag (gimple_call_nothrow ())
> > just amends it.  Guess we might want to fix that (in gimple_call_flags)
> > and then clear the flag always for -fnon-call-exceptions?
> > 
> > I suppose all/most noexcept specifications in libstdc++ are similarly
> > questionable.
> 
> Let's not use too big a hammer though, -fnon-call-exceptions works fine for
> languages (Ada, Go) that enable it by default and I'm quite wary of C++ folks
> who try it once in a while, want to pessimize it because it doesn't work on
> their questionable testcase, and then forget about it.
> 
> Why not just extend what's done in build_common_builtin_nodes for
> __builtin_alloca to the family of __builtin_mem* functions?

Ah, didn't remember this place.  Yes, I guess we could fix that place
but that wouldn't conver the C/C++ frontends since those have
the builtins already (wrongly) declared via the builtins.def machinery
which does mark them NOTHROW (the __builtin_alloca handling also
doesn't work for them).

That means that similar to ATTR_MATHFN_FPROUNDING we'd need a
variants of ATTR_NOTHROW_NONNULL_LEAF and some others that make
the NOTHROW part conditional on flag_non_call_exceptions.
Guess that's doable, double checking LTO behavior on merging
of builtins from different CUs with possibly different settings
of -fnon-call-exceptions needs to be done though.

[Bug middle-end/64101] GCC considers that the erf math function does not set errno

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #5 from Richard Biener  ---
Recent glibc documents

   These functions do not set errno.

(and in fact they do not).  GCC does not elide the erf() call with -O0 which is
how you can verify your erf implementation sets or does not set errno, at -O1
GCC elides the erf call as the result is unused.

According to Joseph glibcs behavior is correct and so is then GCCs.

[Bug fortran/87142] Aliasing issue with overloaded assignment and allocatable components

[mscfd at gmx dot net via Gcc-bugs]

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

--- Comment #4 from martin  ---
With yesterdays master branch, I still see an invalid read with valgrind and an
"AddressSanitizer: heap-use-after-free"-error with -fsanitize=address. So looks
like this has not been fixed by the patch for PR 92178.

[Bug lto/46769] LTO failed to build gold

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #8 from H.J. Lu  ---
GCC 10.2 can build gold with LTO.

[Bug c++/96121] Uninitialized variable copying in member initialized list not diagnosed

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug middle-end/92492] AVX512: Missed vectorization opportunity

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Hongtao.liu  ---
I notice TARGET_VECTORIZE_RELATED_MODE is added, and can be used to handle
convertion, i'm working on this.

[Bug target/97534] [10/11 Regression] ICE in decompose, at rtl.h:2280 (arm-linux-gnueabihf)

[rearnsha at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Richard Earnshaw  ---
No, I don't think it's related to that, in fact, I think this is just a latent
bug that's been in the code for a long time.

At one point we have a 32-bit signed integer containing INT_MIN, which is
internally represented as a 64-bit constant 0x8000; we try to
negate that (so that we can use addition) and end up with 0x8000,
but that's not a canonical value for internal use on an SImode value (they need
to be sign-extended) and eventually this causes the compiler to trip over its
own feet.

I'm testing a patch.

[Bug libstdc++/96322] 22_locale/numpunct/members/char/3.cc is outdated: expects grouping=0, actual=3

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jonathan Wakely  ---
We really need to create our own custom locales for testing, so that we don't
depend on externally defined data that keep changing.

[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool

[wilson at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #35 from Jim Wilson  ---
By combine issue, are you referring to the regression I mentioned in comment 3
and filed as bug 97747?  We can handle that as a separate issue.  It should be
uncommon.  I expect to get much more benefit from this patch than the downside
due to that combine issue.

As for the shorten-memrefs problem, I didn't notice that one in my testing.  It
does need to be fixed.  Taking a look now, it looks pretty simple to fix.  The
code currently looks for MEM, it needs to handle (SIGN_EXTEND (MEM)) and
((ZERO_EXTEND (MEM)).  See the get_si_mem_base_reg function.  You need to skip
over the sign_extend or zero_extend when looking fot the mem at the first call.
 Then at the second call you need to be careful to put the sign_extend or
zero_extend back when creating the new RTL.  Maybe just another arg to
get_si_mem_base so it can record the parent rtx code of the mem.  Or maybe do
this outside get_si_mem_base to skip over a sign/zero extend at the first call,
and then do the same at the second call but record what rtx we skipped over so
that we can put it back.  We can either handle this here or as another patch. 
But since you have some time while waiting for paperwork maybe you can try
writing a fix.

[Bug libstdc++/95048] [9/10/11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

[gcc-bugzilla at m dot chronial.de via Gcc-bugs]

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

--- Comment #9 from Christian Fersch  ---
But is it possible to query the value of -fwide-exec-charset? I had quick look
and couldn't find anything.

[Bug libstdc++/96322] 22_locale/numpunct/members/char/3.cc is outdated: expects grouping=0, actual=3

[slyfox at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Sergei Trofimovich  ---
Maybe pick another similar locale? Candidates are:

glibc $ git grep '0;0' localedata/locales/ | cat
localedata/locales/aa_DJ:grouping   0;0
localedata/locales/bs_BA:grouping  0;0
localedata/locales/el_CY:grouping  0;0
localedata/locales/el_GR:grouping  0;0
localedata/locales/eo:grouping  0;0
localedata/locales/es_CU:grouping 0;0
localedata/locales/gl_ES:grouping 0;0
localedata/locales/mg_MG:grouping  0;0
localedata/locales/pap_AW:grouping  0;0
localedata/locales/pap_CW:grouping  0;0
localedata/locales/pt_PT:grouping  0;0
localedata/locales/sl_SI:grouping  0;0
localedata/locales/sr_RS:grouping  0;0
localedata/locales/ti_ER:grouping  0;0
localedata/locales/wo_SN:grouping  0;0

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #33 from David Malcolm  ---
Patch pushed to master for gcc 11: g:421d0d0f54294a7bf2872b3b2ac521ce0fa9869e
(this bug didn't get notified for some reason).

Changes since v4:
* added location to gcc_jit_context_add_top_level_asm
* more logging
* filter testsuite to x86 targets
* use LIBGCCJIT_ABI_15 and #ifdef LIBGCCJIT_HAVE_ASM_STATEMENTS
* fix asm_operand::make_debug_string
* fixes to write_reproducer
* update expected debug-string results to reflect escaping fixes from
g:fec573408310139e1ffc42741fbe46b4f2947592
* fixed missing comments

Marking this one as resolved.

[Bug rtl-optimization/97777] ICE: in df_refs_verify, at df-scan.c:3991 with -O -ffinite-math-only -fzero-call-used-regs=all

[qinzhao at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from qinzhao at gcc dot gnu.org ---
This does not look like a bug in the new -fzero-call-used-regs implemenation.

it's more likely an existing bug in data flow analysis. 

I made the following change in gcc/function.c to make the new pass to do
nothing except a df_analyze:

qinzhao@gcc10:~/Work/write_gcc/gcc$ git diff function.c
diff --git a/gcc/function.c b/gcc/function.c
index 004fa389207..658b08ae215 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -6658,13 +6658,14 @@ pass_zero_call_used_regs::execute (function *fun)
   /* Iterate over the function's return instructions and insert any
  register zeroing required by the -fzero-call-used-regs command-line
  option or the "zero_call_used_regs" function attribute.  */
+#if 0
   FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR_FOR_FN (cfun)->preds)
 {
   rtx_insn *insn = BB_END (e->src);
   if (JUMP_P (insn) && ANY_RETURN_P (JUMP_LABEL (insn)))
gen_call_used_regs_seq (insn, zero_regs_type);
 }
-
+#endif
   return 0;
 }

with this gcc, the exactly same ICE still there.

[Bug fortran/85796] ICE: Floating point exception

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #6 from anlauf at gcc dot gnu.org ---
Jerry, are you still following this one?

[Bug rtl-optimization/97777] ICE: in df_refs_verify, at df-scan.c:3991 with -O -ffinite-math-only -fzero-call-used-regs=all

[qinzhao at gcc dot gnu.org via Gcc-bugs]

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #2 from qinzhao at gcc dot gnu.org ---
when configured the gcc with --enable-checking=df, I can repeat the failure.
will check what's wrong with the data flow information.

[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
The ICE in comment#0 vanishes when one replaces

  integer,parameter::iarray(merge(2,3,.true.)) = 1

with

  integer,parameter::iarray(merge(2,3,.true.)) = [ 1, 1 ]

[Bug target/97534] [10/11 Regression] ICE in decompose, at rtl.h:2280 (arm-linux-gnueabihf)

[jrtc27 at jrtc27 dot com via Gcc-bugs]

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

James Clarke  changed:

   What|Removed |Added

 CC||jrtc27 at jrtc27 dot com,
   ||rearnsha at arm dot com

--- Comment #4 from James Clarke  ---
[Adding Richard to CC]

Richard, I see you committed a big series of changes in Oct 2019 to
gcc/config/arm that affected subtraction; is it possible one of those broke
this test case?

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from Jonathan Wakely  ---
Nice, with binutils HEAD my gcc-10 build continues. Thanks!

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

[jozefl at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from jozefl at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #15)
> Hmm, I get the same error for a out-of-tree binutils built from today's git
> sources:
> 
> GNU assembler (GNU Binutils) 2.35.50.20201112
> Copyright (C) 2020 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or later.
> This program has absolutely no warranty.
> This assembler was configured for a target of `msp430-elf'.

Sigh, that's a different bug. I removed a GAS option that doesn't do anything,
but is automatically passed by MSP430 GCC 10 ASM_SPEC when certain other
options aren't present. And my GCC 10 tester explicitly uses Binutils 2.34
rather than master, so it went undetected.

Pushed a Binutils fix. gcc-10 branch now builds with latest Binutils.

Thanks for reporting this.

[Bug fortran/97782] [Fortran] Confused location information for OpenACC compute constructs

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

https://gcc.gnu.org/g:9106c51e57c06e88a0dddf994fb5432b4bbe68c0

commit r11-4951-g9106c51e57c06e88a0dddf994fb5432b4bbe68c0
Author: Thomas Schwinge 
Date:   Thu Nov 12 20:07:25 2020 +0100

Adjust 'libgomp.oacc-fortran/attach-descriptor-1.f90' for improved location
information

Fix-up for commit b71ff8c15f5a7d6b1cc1524b4d27843f0d88dbda "Fortran:
improve
location data for OpenACC/OpenMP directives [PR97782]".

libgomp/
PR fortran/97782
* testsuite/libgomp.oacc-fortran/attach-descriptor-1.f90: Adjust.

[Bug c++/63287] __STDCPP_THREADS__ is not defined

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jonathan Wakely  ---
Library patch:

diff --git a/libgcc/gthr.h b/libgcc/gthr.h
index f31cf083cbe5..e6462679b362 100644
--- a/libgcc/gthr.h
+++ b/libgcc/gthr.h
@@ -147,6 +147,13 @@ see the files COPYING3 and COPYING.RUNTIME respectively. 
If not, see
 #endif
 #include "gthr-default.h"

+#if defined __GTHREADS_CXX0X && ! defined __STDCPP_THREADS__
+// The C++ standard says that __STDCPP_THREADS__ should be defined to 1,
+// but G++ does not currently do that (PR c++/63287).
+// Define it here if gthr-default.h defined __GTHREADS_CXX0X.
+# define __STDCPP_THREADS__ 1
+#endif
+
 #ifndef HIDE_EXPORTS
 #pragma GCC visibility pop
 #endif
diff --git a/libstdc++-v3/include/Makefile.am
b/libstdc++-v3/include/Makefile.am
index 292d89da8ba7..74e3e4932579 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -1316,6 +1316,7 @@ uppercase = [ABCDEFGHIJKLMNOPQRSTUVWXYZ_]

 ${host_builddir}/gthr.h: ${toplevel_srcdir}/libgcc/gthr.h stamp-${host_alias}
sed -e '/^#pragma/b' \
+   -e '/__STDCPP_THREADS__/b' \
-e '/^#/s/\(${uppercase}${uppercase}*\)/_GLIBCXX_\1/g' \
-e 's/_GLIBCXX_SUPPORTS_WEAK/__GXX_WEAK__/g' \
-e 's/_GLIBCXX___MINGW32_GLIBCXX___/__MINGW32__/g' \

[Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)

[bunk at stusta dot de via Gcc-bugs]

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

--- Comment #5 from Adrian Bunk  ---
(In reply to Richard Biener from comment #4)
> You can also try to 'reduce' the testcase.  Since you are linking a shared
> object you can try to strip as many linker inputs as possible and then
> reduce the source files.

Bisecting does not work when both halves are working, but I now found some
clues:

$ g++ -flto -shared CMakeFiles/cpp.dir/src/dolfin.cpp.o
CMakeFiles/cpp.dir/src/parameter.cpp.o CMakeFiles/cpp.dir/src/adaptivity.cpp.o
CMakeFiles/cpp.dir/src/ale.cpp.o CMakeFiles/cpp.dir/src/common.cpp.o
CMakeFiles/cpp.dir/src/fem.cpp.o CMakeFiles/cpp.dir/src/function.cpp.o
CMakeFiles/cpp.dir/src/generation.cpp.o CMakeFiles/cpp.dir/src/geometry.cpp.o
CMakeFiles/cpp.dir/src/graph.cpp.o CMakeFiles/cpp.dir/src/log.cpp.o
CMakeFiles/cpp.dir/src/math.cpp.o CMakeFiles/cpp.dir/src/mesh.cpp.o
CMakeFiles/cpp.dir/src/multistage.cpp.o CMakeFiles/cpp.dir/src/ts.cpp.o
CMakeFiles/cpp.dir/src/io.cpp.o CMakeFiles/cpp.dir/src/la.cpp.o
CMakeFiles/cpp.dir/src/nls.cpp.o CMakeFiles/cpp.dir/src/refinement.cpp.o
CMakeFiles/cpp.dir/src/MPICommWrapper.cpp.o
/usr/bin/ld: /tmp/ccofV1SZ.ltrans32.ltrans.o: .symtab local symbol at index 214
(>= sh_info of 34)
/usr/bin/ld: /tmp/ccofV1SZ.ltrans32.ltrans.o: error adding symbols: bad value
collect2: error: ld returned 1 exit status
$  g++ -flto -shared dolfin.ii parameter.ii adaptivity.ii ale.ii common.ii
fem.ii function.ii generation.ii geometry.ii graph.ii log.ii math.ii mesh.ii
multistage.ii ts.ii io.ii la.ii nls.ii refinement.ii MPICommWrapper.ii
/tmp/ccraiNyo.ltrans9.ltrans.o: in function
`std::__exception_ptr::exception_ptr::operator=(std::__exception_ptr::exception_ptr&&)':
:(.text+0x290): relocation truncated to fit: R_MIPS_CALL16 against
`std::__exception_ptr::exception_ptr::~exception_ptr()@@CXXABI_1.3.3'
/tmp/ccraiNyo.ltrans9.ltrans.o: in function `std::__cxx11::to_string(int)':
:(.text+0x414): relocation truncated to fit: R_MIPS_CALL16 against
`std::__cxx11::basic_string, std::allocator
>::basic_string(unsigned long, char, std::allocator
const&)@@GLIBCXX_3.4.21'
:(.text+0x42c): relocation truncated to fit: R_MIPS_CALL16 against
`std::allocator::~allocator()@@GLIBCXX_3.4'
:(.text+0x498): relocation truncated to fit: R_MIPS_CALL16 against
`std::allocator::~allocator()@@GLIBCXX_3.4'
:(.text+0x4b0): relocation truncated to fit: R_MIPS_CALL16 against
`_Unwind_Resume@@GCC_3.0'
:(.text+0x4e0): relocation truncated to fit: R_MIPS_CALL16 against
`_Unwind_Resume@@GCC_3.0'
/tmp/ccraiNyo.ltrans9.ltrans.o: in function `std::__cxx11::to_string(unsigned
long)':
:(.text+0x584): relocation truncated to fit: R_MIPS_CALL16 against
`std::__cxx11::basic_string, std::allocator
>::basic_string(unsigned long, char, std::allocator
const&)@@GLIBCXX_3.4.21'
:(.text+0x598): relocation truncated to fit: R_MIPS_CALL16 against
`std::allocator::~allocator()@@GLIBCXX_3.4'
:(.text+0x5c8): relocation truncated to fit: R_MIPS_CALL16 against
`std::__cxx11::basic_string, std::allocator
>::size() const@@GLIBCXX_3.4.21'
:(.text+0x610): relocation truncated to fit: R_MIPS_CALL16 against
`std::allocator::~allocator()@@GLIBCXX_3.4'
:(.text+0x628): additional relocation overflows omitted from the
output
collect2: error: ld returned 1 exit status
$ g++ -flto -shared dolfin.ii parameter.ii adaptivity.ii ale.ii common.ii
fem.ii function.ii generation.ii geometry.ii graph.ii log.ii math.ii mesh.ii
multistage.ii ts.ii io.ii la.ii nls.ii refinement.ii MPICommWrapper.ii -mxgot
$ g++ -flto -shared CMakeFiles/cpp.dir/src/dolfin.cpp.o
CMakeFiles/cpp.dir/src/parameter.cpp.o CMakeFiles/cpp.dir/src/adaptivity.cpp.o
CMakeFiles/cpp.dir/src/ale.cpp.o CMakeFiles/cpp.dir/src/common.cpp.o
CMakeFiles/cpp.dir/src/fem.cpp.o CMakeFiles/cpp.dir/src/function.cpp.o
CMakeFiles/cpp.dir/src/generation.cpp.o CMakeFiles/cpp.dir/src/geometry.cpp.o
CMakeFiles/cpp.dir/src/graph.cpp.o CMakeFiles/cpp.dir/src/log.cpp.o
CMakeFiles/cpp.dir/src/math.cpp.o CMakeFiles/cpp.dir/src/mesh.cpp.o
CMakeFiles/cpp.dir/src/multistage.cpp.o CMakeFiles/cpp.dir/src/ts.cpp.o
CMakeFiles/cpp.dir/src/io.cpp.o CMakeFiles/cpp.dir/src/la.cpp.o
CMakeFiles/cpp.dir/src/nls.cpp.o CMakeFiles/cpp.dir/src/refinement.cpp.o
CMakeFiles/cpp.dir/src/MPICommWrapper.cpp.o -flto-partition=none
$ 

Adding -mxgot to compiler and linker flags of a normal LTO build does not work,
but -flto-partition=none during linking is a workaround.

[Bug c++/97814] Copy constructor deletion not recognized in initialization list with -std=c++17

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jonathan Wakely  ---
N.B. that's not a copy constructor, it's a move constructor.

[Bug c++/97814] Copy constructor deletion not recognized in initialization list with -std=c++17

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jonathan Wakely  ---
There is no copy in C++17, it is elided, so lock(S(1)) is equivalent to lock(1)
in C++17, and that constructor exists.

GCC is correct.

[Bug c++/63287] __STDCPP_THREADS__ is not defined

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jonathan Wakely  ---
I tried to implement this by adding a macro definition to c_cpp_builtins in
gcc/c-family/c-cppbuiltin.c but failed. I think we want to inspect the
'thread_model' global variable and see if it is "single", but that might only
be available to the driver, not cc1plus.

Maybe the driver needs to check THREAD_MODEL_SPEC and thread_model and then
pass -D__STDCPP_THREADS__=1 to cc1plus when strcmp(thread_model, "single").

For now, I think we can define it in libstdc++'s  based on
the value of the _GLIBCXX_HAS_GTHREADS macro.

[Bug rtl-optimization/97777] ICE: in df_refs_verify, at df-scan.c:3991 with -O -ffinite-math-only -fzero-call-used-regs=all

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||qing.zhao at oracle dot com
   Last reconfirmed||2020-11-12
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.0
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Confirmed (compiler must be configured with checking enabled).

CC author.

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #15 from Jonathan Wakely  ---
Hmm, I get the same error for a out-of-tree binutils built from today's git
sources:

GNU assembler (GNU Binutils) 2.35.50.20201112
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `msp430-elf'.

[Bug c++/97814] Copy constructor deletion not recognized in initialization list with -std=c++17

[caparson at uwaterloo dot ca via Gcc-bugs]

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

--- Comment #1 from Colby Parsons  ---
It is worth mentioning that the error does appear if I delete the move
assignment operator too.

i.e. add "S & operator=(S &&) = delete;" to struct S.

I have no idea why this would make the error appear though.

[Bug c++/97814] New: Copy constructor deletion not recognized in initialization list with -std=c++17

[caparson at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 97814
   Summary: Copy constructor deletion not recognized in
initialization list with -std=c++17
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: caparson at uwaterloo dot ca
  Target Milestone: ---

Created attachment 49553
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49553=edit
A short 12 line code snippet that when compiled reproduces the bug.

When compiling the attached program with the command "gcc copyConstruct.cc
-std=c++17" it does not produce the following error:

copyConstruct.cc:11:20: error: use of deleted function ‘S::S(S&&)’
   11 | C() : lock(S(1)) {}
  |^
copyConstruct.cc:4:5: note: declared here
4 | S( S && ) = delete;
  | ^

But it does with the command "gcc copyConstruct.cc -std=c++14".

It seems to not recognize that the copy constructor is deleted when it is used
in an initializer list.

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

[jozefl at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from jozefl at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #13)
> I tried a bootstrap of gcc-10 and I get this error during libgcc/configure
> 
> conftest.s: Assembler messages:
> conftest.s:168: Error: unknown pseudo-op: `.mspabi_attribute'
> conftest.s:169: Error: unknown pseudo-op: `.mspabi_attribute'
> conftest.s:170: Error: unknown pseudo-op: `.mspabi_attribute'
> 
> This is using the same binutils that I used to successfully bootstrap trunk:
> 
> GNU assembler (GNU Binutils) 2.32.51.20190613
> Copyright (C) 2019 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or later.
> This program has absolutely no warranty.
> This assembler was configured for a target of `msp430-elf'.

.mspabi_attribute was only supported since Binutils 2.34. Until GCC commit
b75863a88ec, the preprocessor conditional that tries to switch off
.mspabi_attribute emission wasn't implemented correctly, and didn't switch it
off. The conftest was also wrong, and always fails for an out of tree Binutils.

So if you're using an out of tree Binutils version < 2.34, the conftest fails,
but GCC will still generate the assembler directive that is unsupoprted.

An in-tree Binutils < 2.34 or >= 2.34 always works fine.

I should really backport this fix to GCC 10.

[Bug fortran/97782] [Fortran] Confused location information for OpenACC compute constructs

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #5 from Tobias Burnus  ---
FIXED for mainline (GCC 11) and GCC 10.

If the testcase is not covered by your upcoming patch merges, feel free to
commit it yourself (or tell me to commit it for you).

Thanks for the report!

[Bug fortran/95847] [9/10/11 Regression] Internal error when processing pFUnit generated files with --coverage

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #12 from Tobias Burnus  ---
FIXED on the GCC 11 (mainline), GCC 10 and GCC 9.

Thanks again for the report.

@johannes: As mentioned earlier today – please fill a --coverage bug report for
your C++ testcase, if it still occurs. (This PR only fixed the Fortran issue.)

[Bug fortran/95847] [9/10/11 Regression] Internal error when processing pFUnit generated files with --coverage

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Tobias Burnus
:

https://gcc.gnu.org/g:547d07637bf09d74543f688454ce53a4c5eecd47

commit r9-9041-g547d07637bf09d74543f688454ce53a4c5eecd47
Author: Tobias Burnus 
Date:   Thu Nov 12 16:39:58 2020 +0100

Fortran: Fix function decl's location [PR95847]

gcc/fortran/ChangeLog:

PR fortran/95847
* trans-decl.c (gfc_get_symbol_decl): Do not (re)set the location
of an external procedure.
(build_entry_thunks, generate_coarray_init, create_main_function,
gfc_generate_function_code): Use fndecl's location in BIND_EXPR.

gcc/testsuite/ChangeLog:

PR fortran/95847
* gfortran.dg/coverage.f90: New test.

(cherry picked from commit 2d59593105d3b1e38e49f96b74fd81e4e5038c7f)

[Bug fortran/97799] Passing CHARACTER*(*) var(*) through ENTRY causes segfaults

[hockney at jpl dot nasa.gov via Gcc-bugs]

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

George Hockney  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #11 from George Hockney  ---
We've verified a large-scale legacy build against 

GNU Fortran (gcc8.2) 11.0.0 2020 (experimental)

and

GNU Fortran (GCC) 10.2.1 20201017

All our regressions pass these compilers.

Therefore, I'm changing the status to verified (this is per our bugzilla
workflow; if it's not your workflow please fix)



Unfortunately, 10.2.0 was released with this bug.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #48 from Marek Polacek  ---
I have a patch that for this:

// PR c++/19808
// { dg-do compile { target c++11 } }
// { dg-options "-Wuninitialized" }

struct S {
  int i, j, k, l;
  S() : i(j), // { dg-warning "field .S::j. is uninitialized when used here" }
j(1),
k(l + 1), // { dg-warning "field .S::l. is uninitialized when used
here" }
l(2) { }
};

struct A {
  int a, b, c;
  A() : a(b // { dg-warning "field .A::b. is uninitialized when used here" }
  + c) { } // { dg-warning "field .A::c. is uninitialized when used
here" }
};

struct B {
  int 
  int *p;
  int a;
  B() : r(a), p(), a(1) { }
};

struct C {
  const int , 
  C () : r1(r2), // { dg-warning "reference .C::r2. is not yet bound to a value
when used here" }
 r2(r1) { }
};

struct D {
  int a = 1;
  int b = 2;
  D() : a(b + 1), b(a + 1) { } // { dg-warning "field .D::b. is uninitialized
when used here" }
};

struct E {
  int a = 1;
  E() : a(a + 1) { } // { dg-warning "field .E::a. is uninitialized when used
here" }
};

struct F {
  int a = 1;
  int b;
  F() : b(a + 1) { }
};

struct bar {
  bar() {}
  bar(bar&) {}
};

class foo {
  bar first;
  bar second;
public:
  foo() : first(second) {} // { dg-warning "field .foo::second. is
uninitialized when used here" }
};

does this:

$ ./cc1plus -quiet  -Wuninitialized  Wuninitialized-12.C
Wuninitialized-12.C: In constructor ‘S::S()’:
Wuninitialized-12.C:7:11: warning: field ‘S::j’ is uninitialized when used here
[-Wuninitialized]
7 |   S() : i(j), // { dg-warning "field .S::j. is uninitialized when used
here" }
  |   ^
Wuninitialized-12.C:9:11: warning: field ‘S::l’ is uninitialized when used here
[-Wuninitialized]
9 | k(l + 1), // { dg-warning "field .S::l. is uninitialized when
used here" }
  |   ^
Wuninitialized-12.C: In constructor ‘A::A()’:
Wuninitialized-12.C:15:11: warning: field ‘A::b’ is uninitialized when used
here [-Wuninitialized]
   15 |   A() : a(b // { dg-warning "field .A::b. is uninitialized when used
here" }
  |   ^
Wuninitialized-12.C:16:13: warning: field ‘A::c’ is uninitialized when used
here [-Wuninitialized]
   16 |   + c) { } // { dg-warning "field .A::c. is uninitialized when
used here" }
  | ^
Wuninitialized-12.C: In constructor ‘C::C()’:
Wuninitialized-12.C:28:13: warning: reference ‘C::r2’ is not yet bound to a
value when used here [-Wuninitialized]
   28 |   C () : r1(r2), // { dg-warning "reference .C::r2. is not yet bound to
a value when used here" }
  | ^~
Wuninitialized-12.C: In constructor ‘D::D()’:
Wuninitialized-12.C:35:11: warning: field ‘D::b’ is uninitialized when used
here [-Wuninitialized]
   35 |   D() : a(b + 1), b(a + 1) { } // { dg-warning "field .D::b. is
uninitialized when used here" }
  |   ^
Wuninitialized-12.C: In constructor ‘E::E()’:
Wuninitialized-12.C:40:11: warning: field ‘E::a’ is uninitialized when used
here [-Wuninitialized]
   40 |   E() : a(a + 1) { } // { dg-warning "field .E::a. is uninitialized
when used here" }
  |   ^
Wuninitialized-12.C: In constructor ‘foo::foo()’:
Wuninitialized-12.C:58:17: warning: field ‘foo::second’ is uninitialized when
used here [-Wuninitialized]
   58 |   foo() : first(second) {} // { dg-warning "field .foo::second. is
uninitialized when used here" }
  | ^~

[Bug middle-end/64711] Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations and memmov

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Eric Botcazou  ---
> The issue with clearing nothrow is that those pesky builtins have
> that "sticky" while the per-stmt flag (gimple_call_nothrow ())
> just amends it.  Guess we might want to fix that (in gimple_call_flags)
> and then clear the flag always for -fnon-call-exceptions?
> 
> I suppose all/most noexcept specifications in libstdc++ are similarly
> questionable.

Let's not use too big a hammer though, -fnon-call-exceptions works fine for
languages (Ada, Go) that enable it by default and I'm quite wary of C++ folks
who try it once in a while, want to pessimize it because it doesn't work on
their questionable testcase, and then forget about it.

Why not just extend what's done in build_common_builtin_nodes for
__builtin_alloca to the family of __builtin_mem* functions?

[Bug fortran/97782] [Fortran] Confused location information for OpenACC compute constructs

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Tobias Burnus
:

https://gcc.gnu.org/g:5eebaff9f992814a2f8f915e436716b1b2c983df

commit r10-9018-g5eebaff9f992814a2f8f915e436716b1b2c983df
Author: Tobias Burnus 
Date:   Thu Nov 12 14:16:53 2020 +0100

Fortran: improve location data for OpenACC/OpenMP directives [PR97782]

gcc/fortran/ChangeLog:

PR fortran/97782
* trans-openmp.c (gfc_trans_oacc_construct,
gfc_trans_omp_parallel_do,
gfc_trans_omp_parallel_do_simd, gfc_trans_omp_parallel_sections,
gfc_trans_omp_parallel_workshare, gfc_trans_omp_sections
gfc_trans_omp_single, gfc_trans_omp_task, gfc_trans_omp_teams
gfc_trans_omp_target, gfc_trans_omp_target_data,
gfc_trans_omp_workshare): Use code->loc instead of input_location
when building the OMP_/OACC_ construct.

gcc/testsuite/ChangeLog:

PR fortran/97782
* gfortran.dg/goacc/classify-kernels-unparallelized.f95: Move
dg-message
one line up.
* gfortran.dg/goacc/classify-kernels.f95: Likewise.

Reviewed-by: Thomas Schwinge 

(cherry picked from commit b71ff8c15f5a7d6b1cc1524b4d27843f0d88dbda)

[Bug fortran/95847] [9/10/11 Regression] Internal error when processing pFUnit generated files with --coverage

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Tobias Burnus
:

https://gcc.gnu.org/g:17563c1153d36440936ea0948ac689f84b2cf666

commit r10-9017-g17563c1153d36440936ea0948ac689f84b2cf666
Author: Tobias Burnus 
Date:   Tue Nov 10 10:31:33 2020 +0100

Fortran: Fix function decl's location [PR95847]

gcc/fortran/ChangeLog:

PR fortran/95847
* trans-decl.c (gfc_get_symbol_decl): Do not (re)set the location
of an external procedure.
(build_entry_thunks, generate_coarray_init, create_main_function,
gfc_generate_function_code): Use fndecl's location in BIND_EXPR.

gcc/testsuite/ChangeLog:

PR fortran/95847
* gfortran.dg/coverage.f90: New test.

(cherry picked from commit 2d59593105d3b1e38e49f96b74fd81e4e5038c7f)

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #10 from Jonathan Wakely  ---
Done for 10.3

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:a65261443a9b9cfac876c0b7e47393587eb1ce5c

commit r10-9015-ga65261443a9b9cfac876c0b7e47393587eb1ce5c
Author: Jonathan Wakely 
Date:   Wed Aug 19 20:36:10 2020 +0100

libstdc++: Make make-unsigned-like-t<__int128> work [PR 96042]

As well as ensuring that numeric_limits<__int128> is defined, we need to
ensure that make-unsigned-like-t and to-unsigned-like work correctly for
128-bit integers in strict mode. This ensures that a subrange created
from an iota_view's iterator and sentinel can represent its size.

Co-authored-by: Patrick Palka  

libstdc++-v3/ChangeLog:

2020-08-19  Jonathan Wakely  
Patrick Palka  

PR libstdc++/96042
* include/bits/range_access.h (__detail::__to_unsigned_like):
Do not use make_unsigned_t in the return type, as it can
result in an error before the integral constraint is checked.
[__STRICT_ANSI__]: Add overloads for 128-bit integer types.
(__detail::__make_unsigned_like_t): Define as the return type
of __to_unsigned_like.
* testsuite/std/ranges/subrange/96042.cc: New test.

(cherry picked from commit e6e01618e83bcd9eb3a2b27df30ed87106a748b4)

[Bug libstdc++/97813] std::filesystem::equivalent returning incorrect results on MinGW due to symlinks

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-12
 Status|UNCONFIRMED |NEW
 Target||*-*-mingw*
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
We don't currently support symlinks on Windows. There's a lot more than just
equivalent that needs to change to support them.

[Bug libstdc++/97813] New: std::filesystem::equivalent returning incorrect results on MinGW due to symlinks

[markus.boeck02 at gmail dot com via Gcc-bugs]

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

Bug ID: 97813
   Summary: std::filesystem::equivalent returning incorrect
results on MinGW due to symlinks
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus.boeck02 at gmail dot com
  Target Milestone: ---

Given two std::filesystem::path that are identical except for maybe spelling
std::filesystem::equivalent will fail if the path is a or a subdirectory of a
symlink. This is due to the use of _wstat. Microsoft states here:
https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/14h5k7ff(v=vs.120)
that _wstat does not work with symlinks. Using stat would be possible but
converting to a multibyte coding seems dirty and could lead to localization
issues I believe? There is a forum discussion here that I read through as well.
http://gtk.10911.n7.nabble.com/wstat-on-Windows-actually-stat-stuff-in-general-td19965.html
 

It seems like the best way of working around this is to not use _wstat on
Windows, wherever possible. I saw in the implementation of equivalent that
additional code for windows already exists that opens the files and compares
Fileinformation. Maybe this could be used instead on Windows?

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from Jonathan Wakely  ---
I tried a bootstrap of gcc-10 and I get this error during libgcc/configure

conftest.s: Assembler messages:
conftest.s:168: Error: unknown pseudo-op: `.mspabi_attribute'
conftest.s:169: Error: unknown pseudo-op: `.mspabi_attribute'
conftest.s:170: Error: unknown pseudo-op: `.mspabi_attribute'

This is using the same binutils that I used to successfully bootstrap trunk:

GNU assembler (GNU Binutils) 2.32.51.20190613
Copyright (C) 2019 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `msp430-elf'.

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:8eb9a45e87bdb81cb44948c651edee846c622a0f

commit r10-9014-g8eb9a45e87bdb81cb44948c651edee846c622a0f
Author: Jonathan Wakely 
Date:   Wed Aug 19 16:27:25 2020 +0100

libstdc++: Make __int128 meet integer-class requirements [PR 96042]

Because __int128 can be used as the difference type for iota_view, we
need to ensure that it meets the requirements of an integer-class type.
The requirements in [iterator.concept.winc] p10 include numeric_limits
being specialized and giving meaningful answers. Currently we only
specialize numeric_limits for non-standard integer types in non-strict
modes.  However, nothing prevents us from defining an explicit
specialization for any implementation-defined type, so it doesn't matter
whether std::is_integral<__int128> is true or not.

This patch ensures that the numeric_limits specializations for signed
and unsigned __int128 are defined whenever __int128 is available. It
also makes the __numeric_traits and __int_limits helpers work for
__int128, via a new __gnu_cxx::__is_integer_nonstrict trait.

libstdc++-v3/ChangeLog:

PR libstdc++/96042
* include/ext/numeric_traits.h (__is_integer_nonstrict): New
trait which is true for 128-bit integers even in strict modes.
(__numeric_traits_integer, __numeric_traits): Use
__is_integer_nonstrict instead of __is_integer.
* include/std/limits [__STRICT_ANSI__ && __SIZEOF_INT128__]
(numeric_limits<__int128>, (numeric_limits):
Define.
* testsuite/std/ranges/iota/96042.cc: New test.

(cherry picked from commit 386fd16c551188e20d5b1684b7139e4269f9a739)

[Bug pch/86674] -W(no)-error=invalid-pch does not affect incorrect language warning

[law at redhat dot com via Gcc-bugs]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
Should be fixed on the trunk

[Bug tree-optimization/97424] Warn on invalid shift amount after inlining

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from David Malcolm  ---
The above commit implements it as an analyzer warning.  Should I close this
out, or should we keep it open for the __builtin_warning approach?

[Bug pch/86674] -W(no)-error=invalid-pch does not affect incorrect language warning

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:cb808c583de59ea568fd240144cd9db07272f45e

commit r11-4944-gcb808c583de59ea568fd240144cd9db07272f45e
Author: Nicholas Guriev 
Date:   Thu Nov 12 08:59:35 2020 -0500

Specify reason of -Winvalid-pch warning

gcc/c-family
PR pch/86674
* c-pch.c (c_common_valid_pch): Use cpp_warning with
CPP_W_INVALID_PCH
reason to fix -Werror=invalid-pch and -Wno-error=invalid-pch
switches.

libcpp
PR pch/86674
* files.c (_cpp_find_file): Use CPP_DL_NOTE not CPP_DL_ERROR in
call to
cpp_error.

[Bug libstdc++/95048] [9/10/11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Jonathan Wakely  ---
We do have a codecvt specialization that uses iconv, which would allow us to
convert from the native wide encoding to UTF-8, independent of the locale's
narrow encoding.

[Bug libstdc++/95048] [9/10/11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Christian Fersch from comment #6)
> It seems like the solution would be to use codecvt_utf8 if wchar_t is 32bit
> and  codecvt_utf8_utf16 if wchar_t is 16bit. This also seems to be what
> libc++ is doing. Would you accept a patch for this?

Doesn't this have the problem I pointed out in comment 5? Using codecvt_utf8
assumes that the wchar_t encoding is either UCS-2 or UCS-4. GCC supports
changing that encoding using the -fwide-exec-charset= option.

> Do we need to handle systems where wchar_t is something other than 16 or 32
> bit wide?

No.

[Bug lto/97812] Wrong output when compiling the testcase with -O2 -flto

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #7 from Martin Liška  ---
Started in between GCC 8 and GCC 9, bisecting now.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[avi--- via Gcc-bugs]

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

--- Comment #38 from Avi Kivity  ---
I do not have a patch, and unfortunately, it will take me several months at the
most optimistic least to get up to speed with gcc internals to fix this. I've
switched to clang, but I'd really like to switch back, I miss gcc's better
support for C++20 and also just irrationally prefer it.

I'll cross my fingers and toes for more luck with gcc 11.

[Bug testsuite/97803] c-c++-common/asan/pointer-compare-1.c assumes variable placement

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #4 from H.J. Lu  ---
Created attachment 49552
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49552=edit
A patch

This works with SHF_GNU_RETAIN.

[Bug libstdc++/95048] [9/10/11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

[gcc-bugzilla at m dot chronial.de via Gcc-bugs]

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

Christian Fersch  changed:

   What|Removed |Added

 CC||gcc-bugzilla at m dot 
chronial.de

--- Comment #6 from Christian Fersch  ---
It seems like the solution would be to use codecvt_utf8 if wchar_t is 32bit and
 codecvt_utf8_utf16 if wchar_t is 16bit. This also seems to be what libc++ is
doing. Would you accept a patch for this?

Do we need to handle systems where wchar_t is something other than 16 or 32 bit
wide?

[Bug testsuite/97803] c-c++-common/asan/pointer-compare-1.c assumes variable placement

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Richard Biener from comment #1)
> Does it work if you add -fno-toplevel-reorder?  SHF_GNU_RETAIN should
> preserve the order of vars even if 'used' then.

Linker will reorder section layout when SHF_GNU_RETAIN is used.

[Bug tree-optimization/97808] [11 Regression] ICE at -Os and above: in clean, at tree-ssa-pre.c:2053 since r11-4921-g86cca5cc14602814

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
This was fixed by 64326bb428ac750ec3b0f56c06dfb98277cd41b5

[Bug lto/97812] Wrong output when compiling the testcase with -O2 -flto

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Last reconfirmed||2020-11-12
 Ever confirmed|0   |1

--- Comment #6 from Martin Liška  ---
I can reproduce that, working on that.

[Bug fortran/97799] Passing CHARACTER*(*) var(*) through ENTRY causes segfaults

[tkoenig at gcc dot gnu.org via Gcc-bugs]

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

Thomas Koenig  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #10 from Thomas Koenig  ---
Test case committed to master as
https://gcc.gnu.org/g:3c3beb1a8137460bc485f9fbe3be8b21ee7f91a2 and
to gcc 10 as https://gcc.gnu.org/g:910250c360291074d0908feb111403e6bb3b32ee .

Thanks for the report!

[Bug middle-end/64711] Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations and memmov

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #6 from rguenther at suse dot de  ---
On Thu, 12 Nov 2020, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711
> 
> --- Comment #5 from Eric Botcazou  ---
> > as the comments says the check isn't correct but it might work for simple
> > non-LTO cases.  Anybody willing to try?
> 
> But isn't LTO towards being the default these days?  If so, what's the point 
> of
> punishing every function for something that doesn't really work with LTO?
> 
> Cannot we clear the nothrow flag on the functions selectively instead?

Well, if this is the place to fix we can figure a way to check it
correctly.

The issue with clearing nothrow is that those pesky builtins have
that "sticky" while the per-stmt flag (gimple_call_nothrow ())
just amends it.  Guess we might want to fix that (in gimple_call_flags)
and then clear the flag always for -fnon-call-exceptions?

I suppose all/most noexcept specifications in libstdc++ are similarly
questionable.

[Bug lto/97812] Wrong output when compiling the testcase with -O2 -flto

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Jakub Jelinek  ---
Can you link with -O2 -flto -save-temps -fdump-tree-optimized
and attach your optimized dumps, such that we can find out if it is a problem
during gimple or some target specific bug?

[Bug fortran/95847] [9/10/11 Regression] Internal error when processing pFUnit generated files with --coverage

[burnus at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Tobias Burnus  ---
(In reply to johannes.ziegenbalg from comment #2)
> I get the same bug with GCC 10.2.0 in one of my c++ test-cases.

Johannes: Can you fill a bugreport for the C++ test case? This PR is only about
Fortran – and the fix is for the Fortran front end, only.

Ole: Thanks for the report!

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #37 from Iain Sandoe  ---
(In reply to Avi Kivity from comment #36)
> A reminder that coroutines are crippled without this fixed, as it is
> standard practice these days to use sanitizers.

Although I have taken the PR, please don't let that stop you providing a patch
if you have one.

My volunteer-time is very limited and it's quite likely that I won't get to
this until some time during stage #3.

[Bug objc/77404] Add Wobjc-root-class

[iains at gcc dot gnu.org via Gcc-bugs]

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

Iain Sandoe  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
   Target Milestone|--- |11.0
 Status|NEW |ASSIGNED

[Bug lto/97812] Wrong output when compiling the testcase with -O2 -flto

[qiaopeixin at huawei dot com via Gcc-bugs]

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

--- Comment #4 from qiaopeixin at huawei dot com ---
(In reply to Martin Liška from comment #2)
> Which git revision of GCC 11 do you use?

Test it using GCC 11 with commit id 3c3beb1a8137460bc485f9fbe3be8b21ee7f91a2
just now and it also fails. It works using GCC 7.3.0 or 8.4.0, and it fails
using GCC 9.3.0, GCC 10.1.0 or current GCC trunk.

[Bug fortran/97782] [Fortran] Confused location information for OpenACC compute constructs

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:b71ff8c15f5a7d6b1cc1524b4d27843f0d88dbda

commit r11-4942-gb71ff8c15f5a7d6b1cc1524b4d27843f0d88dbda
Author: Tobias Burnus 
Date:   Thu Nov 12 14:13:45 2020 +0100

Fortran: improve location data for OpenACC/OpenMP directives [PR97782]

gcc/fortran/ChangeLog:

PR fortran/97782
* trans-openmp.c (gfc_trans_oacc_construct,
gfc_trans_omp_parallel_do,
gfc_trans_omp_parallel_do_simd, gfc_trans_omp_parallel_sections,
gfc_trans_omp_parallel_workshare, gfc_trans_omp_sections
gfc_trans_omp_single, gfc_trans_omp_task, gfc_trans_omp_teams
gfc_trans_omp_target, gfc_trans_omp_target_data,
gfc_trans_omp_workshare): Use code->loc instead of input_location
when building the OMP_/OACC_ construct.

gcc/testsuite/ChangeLog:

PR fortran/97782
* gfortran.dg/goacc/classify-kernels-unparallelized.f95: Move
dg-message
one line up.
* gfortran.dg/goacc/classify-kernels.f95: Likewise.

[Bug lto/97812] Wrong output when compiling the testcase with -O2 -flto

[qiaopeixin at huawei dot com via Gcc-bugs]

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

--- Comment #3 from qiaopeixin at huawei dot com ---
(In reply to Jakub Jelinek from comment #1)
> On which target?  Can't reproduce on x86_64-linux.

aarch64

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

[jozefl at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from jozefl at gcc dot gnu.org ---
Thanks!

I've set off a full msp430-elf build and regtest.

I'll look at backporting it to GCC8/9/10 branches after testing.

[Bug tree-optimization/97808] [11 Regression] ICE at -Os and above: in clean, at tree-ssa-pre.c:2053 since r11-4921-g86cca5cc14602814

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-12
 Ever confirmed|0   |1
Summary|ICE at -Os and above: in|[11 Regression] ICE at -Os
   |clean, at   |and above: in clean, at
   |tree-ssa-pre.c:2053 |tree-ssa-pre.c:2053 since
   ||r11-4921-g86cca5cc14602814
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Confirmed, started with r11-4921-g86cca5cc14602814.

[Bug tree-optimization/97808] [11 Regression] ICE at -Os and above: in clean, at tree-ssa-pre.c:2053 since r11-4921-g86cca5cc14602814

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Keywords||ice-on-valid-code
   Priority|P3  |P1
  Known to work||10.2.0
  Known to fail||11.0

[Bug lto/97812] Wrong output when compiling the testcase with -O2 -flto

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Martin Liška  ---
Which git revision of GCC 11 do you use?

[Bug lto/97812] Wrong output when compiling the testcase with -O2 -flto

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
On which target?  Can't reproduce on x86_64-linux.

[Bug lto/97812] New: Wrong output when compiling the testcase with -O2 -flto

[qiaopeixin at huawei dot com via Gcc-bugs]

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

Bug ID: 97812
   Summary: Wrong output when compiling the testcase with -O2
-flto
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qiaopeixin at huawei dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hi, gcc-trunk outputs wrong result when compiling the following testcase with
-O2 -flto:

#include
short a;
volatile short b = 4066;
char c;
int main() {
  unsigned d = b & 2305;
  signed char e = d;
  c = e ? : e;
  if (d) {
printf("%d\n", a);
  }
}

$gcc -O0 -w test.c && ./a.out
0

$gcc -O2 -flto -w test.c && ./a.out
(nothing)

gcc version 11.0.0 2020 (experimental) (GCC)

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from Jonathan Wakely  ---
Fixed for gcc-11 but it should be backported too. Even if the compiler doesn't
reject the overflow in the constant expressions, the values of the trait are
still wrong for __int20.

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:7f851c33411fc39982c62a91fa93ec02981fd956

commit r11-4941-g7f851c33411fc39982c62a91fa93ec02981fd956
Author: Jonathan Wakely 
Date:   Thu Nov 12 10:29:21 2020 +

libstdc++: Fix __numeric_traits_integer<__int20> [PR 97798]

The expression used to calculate the maximum value for an integer type
assumes that the number of bits in the value representation is always
sizeof(T) * CHAR_BIT. This is not true for the __int20 type on msp430,
which has only 20 bits in the value representation but 32 bits in the
object representation. This causes an integer overflow in a constant
expression, which is ill-formed.

This problem was already solved by DJ for std::numeric_limits<__int20>
by generalizing the helper macros to use a specified number of bits
instead of assuming sizeof(T) * CHAR_BIT. Then the INT_N_n types can
specify the number of bits using the __GLIBCXX_BITSIZE_INT_N_n macros
that the compiler defines.

I'm using a slightly different approach here. I've replaced the helper
macros entirely, and just expanded the calculations in the initializers
for the static data members. By reordering the data members we can reuse
__is_signed and __digits in the other initializers. This removes the
repetition of expanding __glibcxx_signed(T) and __glibcxx_digits(T)
multiple times in each initializer.

The __is_integer_nonstrict trait now defines a new constant, __width,
which is sizeof(T) * CHAR_BIT by default (defined as an enumerator so
that no storage is needed for a static data member). By specializing
__is_integer_nonstrict for the INT_N types that have padding bits, we
can provide the correct width via the __GLIBCXX_BITSIZE_INT_N_n macros.

libstdc++-v3/ChangeLog:

PR libstdc++/97798
* include/ext/numeric_traits.h (__glibcxx_signed)
(__glibcxx_digits, __glibcxx_min, __glibcxx_max): Remove
macros.
(__is_integer_nonstrict::__width): Define new constant.
(__numeric_traits_integer): Define constants in terms of each
other and __is_integer_nonstrict::__width, rather than the
removed macros.
(_GLIBCXX_INT_N_TRAITS): Macro to define explicit
specializations for non-standard integer types.

[Bug debug/97811] New: Adding transparent_union tag when typedeffing compiles but produces no debug info for components of the union

[peadar at arista dot com via Gcc-bugs]

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

Bug ID: 97811
   Summary: Adding transparent_union tag when typedeffing compiles
but produces no debug info for components of the union
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peadar at arista dot com
  Target Milestone: ---

Created attachment 49551
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49551=edit
Source file for good/bad example.

This is against 
gcc (GCC) 10.2.1 20201016 (Red Hat 10.2.1-6)

But exists as far back as gcc8.4 at least.


transparent_enum's are used in glibc for example, with __SOCKADDR_ARG to allow
any type of the numerous address family's variants of sockaddr to be passed to
functions such as bind(2).

The type __SOCKADDR_ARG is declared something like this:

typedef union  {
sockaddr * restrict __sockadddr__;
sockaddr_in * restrict __sockadddr_in__;
/* more sockaddr_* types ... */
} __SOCKADDR_ARG __attribute__((transparent_union));

When compiled with -g, the resulting debug information does not contain any
entries for the fields of the DIE for the (anonymous) union.

The construction looked a little odd to me - it seemed that the attribute is
being applied to the typedef, rather than the union itself, but gcc was happy
to compile it, and the type behaves as expected when passing arguments to
bind(2), for example.

By putting the attribute before the __SOCKADDR_ARG token, it actually fixes the
problem, but it seems either the debug information should be propagated to the
union, or that the compiler should complain.

The attachment is a source file transparent-union.c, and embedded a comment
that is the output of `readelf --debug-dump=info transparent-union.o`. You can
see that for UGood, there's a typedef to the union, and the union has child
DIEs for each member. For UBad, there's the typedef and the union, but no
members.

gdb is, of course, unable to print the content of the problematic union when
debugging, and other tools are equally unhappy.

[Bug c/97810] New: [OpenACC] [C/C++] Decide about 'acc atomic update capture' – remove support or keep it

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97810
   Summary: [OpenACC] [C/C++] Decide about 'acc atomic update
capture' – remove support or keep it
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: tschwinge at gcc dot gnu.org
  Target Milestone: ---

OpenACC between 2.5 and 3.0 permits

  #pragma acc atomic update capture'
 structured-block

For OpenACC 3.1, it was decided that this is a copy'n'paste error and it should
have been 'acc atomic capture' instead (i.e. no 'update' before 'capture').

(The Fortran version of the spec never supported '!$acc atomic update
capture'.)

GCC 11 added support for 'update capture' (in C/C++ only) as alias for
'capture'.

Question: Should the support be removed again?

See OpenACC 3.1 spec, once released, and (nonpublic) issue
https://github.com/OpenACC/openacc-spec/issues/333

[Bug c++/97790] constexpr evaluation reports false positive memory leak

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed for 10.3/11.

[Bug target/97730] [10 Regression] aarch64, SVE2: Wrong code since r10-5853-g0a09a948 (wrong pattern for BCAX)

[acoplan at gcc dot gnu.org via Gcc-bugs]

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

Alex Coplan  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-12
Summary|[10/11 Regression] aarch64, |[10 Regression] aarch64,
   |SVE2: Wrong code since  |SVE2: Wrong code since
   |r10-5853-g0a09a948 (wrong   |r10-5853-g0a09a948 (wrong
   |pattern for BCAX)   |pattern for BCAX)
   Assignee|unassigned at gcc dot gnu.org  |acoplan at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Alex Coplan  ---
Fixed on trunk, will backport to GCC 10 in a few days.

[Bug target/97730] [10/11 Regression] aarch64, SVE2: Wrong code since r10-5853-g0a09a948 (wrong pattern for BCAX)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Alex Coplan :

https://gcc.gnu.org/g:7f445b5d6116000f1a6527f2164836cbc7c01dee

commit r11-4938-g7f445b5d6116000f1a6527f2164836cbc7c01dee
Author: Alex Coplan 
Date:   Thu Nov 12 10:03:21 2020 +

aarch64: Fix SVE2 BCAX pattern [PR97730]

This patch adds a missing not to the SVE2 BCAX (Bitwise clear and
exclusive or) pattern, fixing the PR. Since SVE doesn't have an
unpredicated not instruction, we need to use a (vacuously) predicated
not here.

To ensure that the predicate is instantiated correctly (to all 1s) for
the intrinsics, we pull out a separate expander from the define_insn.

From the ISA reference [1]:
> Bitwise AND elements of the second source vector with the
> corresponding inverted elements of the third source vector, then
> exclusive OR the results with corresponding elements of the first
> source vector.

[1] :
https://developer.arm.com/docs/ddi0602/g/a64-sve-instructions-alphabetic-order/bcax-bitwise-clear-and-exclusive-or

gcc/ChangeLog:

PR target/97730
* config/aarch64/aarch64-sve2.md (@aarch64_sve2_bcax):
Change to define_expand, add missing (trivially-predicated) not
rtx to fix wrong code bug.
(*aarch64_sve2_bcax): New.

gcc/testsuite/ChangeLog:

PR target/97730
* gcc.target/aarch64/sve2/bcax_1.c (OP): Add missing bitwise not
to match correct bcax semantics.
* gcc.dg/vect/pr97730.c: New test.

[Bug c/97748] Preincrement of _Complex gives bogus warning = "value computed is not used"

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:9d488c191c62cb114fa40239c495ac773ff76751

commit r10-9011-g9d488c191c62cb114fa40239c495ac773ff76751
Author: Jakub Jelinek 
Date:   Tue Nov 10 15:56:20 2020 +0100

c, c++: Fix up -Wunused-value on COMPLEX_EXPRs [PR97748]

The -Wunused-value warning in both C and C++ FEs (implemented
significantly differently between the two) sees the COMPLEX_EXPRs created
e.g. for complex pre/post increment and many other expressions as useless
and warns about it.

For the C warning implementation, on e.g.
COMPLEX_EXPR < ++REALPART_EXPR , IMAGPART_EXPR >;
would warn even on the IMAGPART_EXPR  there alone etc., so what works
is check if we'd warn about both operands of COMPLEX_EXPR and if yes,
warn on the whole COMPLEX_EXPR, otherwise don't warn.

The C++ warning implementation is significantly different and for that one
the only warn if both would be warned about doesn't really work,
we then miss warnings e.g. about
COMPLEX_EXPR > + 1.0e+0, IMAGPART_EXPR
>> >
The patch replaces the warning_at call with call to the c-family
warn_if_unused_value function.

On the testcase which after the initial new tests contains pretty much
everything from gcc.dg/Wunused-value-1.c both approaches seem to work
nicely.

2020-11-10  Jakub Jelinek  

PR c/97748
gcc/c-family/
* c-common.h (warn_if_unused_value): Add quiet argument defaulted
to false.
* c-warn.c (warn_if_unused_value): Likewise.  Pass it down
recursively and just return true instead of warning if it is true.
Handle COMPLEX_EXPR.
gcc/cp/
* cvt.c (convert_to_void): Check (complain & tf_warning) in the
outer
if rather than twice times in the inner one.  Use
warn_if_unused_value.
Formatting fix.
gcc/testsuite/
* c-c++-common/Wunused-value-1.c: New test.

(cherry picked from commit ea4fb4eaacbd2c954d78d7f8e9f03c7be739)

[Bug c++/97663] [c++17] Function with return type 'unsigned' in nested namespace misinterpreted as deduction guide

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:cd41e4a1864c10c7f9141284e82e5cc0a3007806

commit r10-9008-gcd41e4a1864c10c7f9141284e82e5cc0a3007806
Author: Jakub Jelinek 
Date:   Tue Nov 3 21:42:51 2020 +0100

c++: Don't try to parse a function declaration as deduction guide [PR97663]

While these function declarations have NULL decl_specifiers->type,
they have still type specifiers specified from which the default int
in the return type is added, so we shouldn't try to parse those as
deduction guides.

2020-11-03  Jakub Jelinek  

PR c++/97663
* parser.c (cp_parser_init_declarator): Don't try to parse
C++17 deduction guides if there are any type specifiers even when
type is NULL.

* g++.dg/cpp1z/class-deduction75.C: New test.

(cherry picked from commit 875225301e356759982573d5578ed7ca54f81f86)

[Bug c++/97790] constexpr evaluation reports false positive memory leak

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:d183dd5ca42bbfc1f840c59ffe2e42fbd6860707

commit r10-9012-gd183dd5ca42bbfc1f840c59ffe2e42fbd6860707
Author: Jakub Jelinek 
Date:   Thu Nov 12 10:46:04 2020 +0100

c++: Fix up constexpr CLEANUP_POINT_EXPR and TRY_FINALLY_EXPR handling
[PR97790]

As the testcase shows, CLEANUP_POINT_EXPR (and I think TRY_FINALLY_EXPR
too)
suffer from the same problem that I was trying to fix in
r10-3597-g1006c9d4395a939820df76f37c7b085a4a1a003f
for CLEANUP_STMT, namely that if in the middle of the body expression of
those stmts is e.g. return stmt, goto, break or continue (something that
changes *jump_target and makes it start skipping stmts), we then skip the
cleanups too, which is not appropriate - the cleanups were either queued up
during the non-skipping execution of the body (for CLEANUP_POINT_EXPR), or
for TRY_FINALLY_EXPR are relevant already after entering the body block.

> Would it make sense to always use a NULL jump_target when evaluating
> cleanups?

I was afraid of that, especially for TRY_FINALLY_EXPR, but it seems that
during constexpr evaluation the cleanups will most often be just very
simple
destructor calls (or calls to cleanup attribute functions).
Furthermore, for neither of these 3 tree codes we'll reach that code if
jump_target && *jump_target initially (there is a return NULL_TREE much
earlier for those except for trees that could embed labels etc. in it and
clearly these 3 don't count in that).

2020-11-12  Jakub Jelinek  

PR c++/97790
* constexpr.c (cxx_eval_constant_expression) : Don't pass jump_target
to
cxx_eval_constant_expression when evaluating the cleanups.

* g++.dg/cpp2a/constexpr-dtor9.C: New test.

(cherry picked from commit fc531c2ed3ce456efca946e995544b216b3c16df)

[Bug c++/67453] vtable not emitted for class with no key method and defaulted destructor with attribute((used))

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:921661beb90edd14a6102e87f0ff71b5a21a70ee

commit r10-9010-g921661beb90edd14a6102e87f0ff71b5a21a70ee
Author: Jakub Jelinek 
Date:   Fri Nov 6 20:33:39 2020 +0100

c++: Propagate attributes to clones in duplicate_decls [PR67453]

On the following testcase where the cdtor attributes aren't on the
in-class declaration but on an out-of-class definition, the cdtors
have their clones created from the in-class declaration, and later on
duplicate_decls updates attributes on the abstract cdtors, but nothing
propagates them to the clones.

2020-11-06  Jakub Jelinek  

PR c++/67453
* decl.c (duplicate_decls): Propagate DECL_ATTRIBUTES and
DECL_PRESERVE_P from olddecl to its clones if any.

* g++.dg/ext/attr-used-2.C: New test.

(cherry picked from commit 6c282c14d1be0bba2bf5d49acd074b349f28ad17)

[Bug bootstrap/97806] [11 regression] bootstrap ICE starting with r11-4921

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:64326bb428ac750ec3b0f56c06dfb98277cd41b5

commit r11-4937-g64326bb428ac750ec3b0f56c06dfb98277cd41b5
Author: Richard Biener 
Date:   Thu Nov 12 09:10:51 2020 +0100

tree-optimization/97806 - fix PRE expression post order

This fixes the postorder compute for the case of multiple
expression leaders for a value.

2020-11-12  Richard Biener  

PR tree-optimization/97806
* tree-ssa-pre.c (pre_expr_DFS): New overload for visiting
values, visiting all leaders for a value.  Use a bitmap
for visited values.
(sorted_array_from_bitmap_set): Walk over values and adjust.

* gcc.dg/pr97806.c: New testcase.

[Bug bootstrap/97806] [11 regression] bootstrap ICE starting with r11-4921

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

[jozefl at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from jozefl at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #8)
> My attempt to build msp430 fails with:
> 
> In file included from
> /home/jwakely/gcc/msp430-elf/msp430-elf/include/stdint.h:13,
>  from
> /home/jwakely/src/gcc/build-16bit/gcc/include/stdint.h:9,
>  from
> /home/jwakely/src/gcc/build-16bit/msp430-elf/large/libstdc++-v3/include/bits/
> align.h:36,
>  from
> /home/jwakely/src/gcc/build-16bit/msp430-elf/large/libstdc++-v3/include/
> memory:72,
>  from
> /home/jwakely/src/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h:82:
> /home/jwakely/gcc/msp430-elf/msp430-elf/include/sys/_intsup.h:68:2: error:
> #error "Unable to determine type definition of intptr_t"
>68 | #error "Unable to determine type definition of intptr_t"
>   |  ^
> 
> 
> Is that related?

Newlib is required for MSP430. Symlink the newlib/ and libgloss/ subdirs into
the GCC tree root.

[Bug c++/97790] constexpr evaluation reports false positive memory leak

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:fc531c2ed3ce456efca946e995544b216b3c16df

commit r11-4936-gfc531c2ed3ce456efca946e995544b216b3c16df
Author: Jakub Jelinek 
Date:   Thu Nov 12 10:46:04 2020 +0100

c++: Fix up constexpr CLEANUP_POINT_EXPR and TRY_FINALLY_EXPR handling
[PR97790]

As the testcase shows, CLEANUP_POINT_EXPR (and I think TRY_FINALLY_EXPR
too)
suffer from the same problem that I was trying to fix in
r10-3597-g1006c9d4395a939820df76f37c7b085a4a1a003f
for CLEANUP_STMT, namely that if in the middle of the body expression of
those stmts is e.g. return stmt, goto, break or continue (something that
changes *jump_target and makes it start skipping stmts), we then skip the
cleanups too, which is not appropriate - the cleanups were either queued up
during the non-skipping execution of the body (for CLEANUP_POINT_EXPR), or
for TRY_FINALLY_EXPR are relevant already after entering the body block.

> Would it make sense to always use a NULL jump_target when evaluating
> cleanups?

I was afraid of that, especially for TRY_FINALLY_EXPR, but it seems that
during constexpr evaluation the cleanups will most often be just very
simple
destructor calls (or calls to cleanup attribute functions).
Furthermore, for neither of these 3 tree codes we'll reach that code if
jump_target && *jump_target initially (there is a return NULL_TREE much
earlier for those except for trees that could embed labels etc. in it and
clearly these 3 don't count in that).

2020-11-12  Jakub Jelinek  

PR c++/97790
* constexpr.c (cxx_eval_constant_expression) : Don't pass jump_target
to
cxx_eval_constant_expression when evaluating the cleanups.

* g++.dg/cpp2a/constexpr-dtor9.C: New test.

[Bug bootstrap/97806] [11 regression] bootstrap ICE starting with r11-4921

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #5 from Tamar Christina  ---
*** Bug 97809 has been marked as a duplicate of this bug. ***

[Bug bootstrap/97809] [11 Regression] AArch64 bootstrap broken, ICE when building mpf after g:86cca5cc14602814b98e55aae313fbe237af1b04

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #2 from Tamar Christina  ---
Ah indeed, missed that

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

[Bug bootstrap/97809] [11 Regression] AArch64 bootstrap broken, ICE when building mpf after g:86cca5cc14602814b98e55aae313fbe237af1b04

[acoplan at gcc dot gnu.org via Gcc-bugs]

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

Alex Coplan  changed:

   What|Removed |Added

 CC||acoplan at gcc dot gnu.org

--- Comment #1 from Alex Coplan  ---
Looks like a dup of 97806?

[Bug bootstrap/97809] New: [11 Regression] AArch64 bootstrap broken, ICE when building mpf after g:86cca5cc14602814b98e55aae313fbe237af1b04

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97809
   Summary: [11 Regression] AArch64 bootstrap broken, ICE when
building mpf after
g:86cca5cc14602814b98e55aae313fbe237af1b04
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

The assert introduced here seems to get hit during stage 3 when building mpfr.

during GIMPLE pass: pre
../../.././mpfr/src/sub1sp.c: In function 'mpfr_sub1sp':
../../.././mpfr/src/sub1sp.c:135:1: internal compiler error: in clean, at
tree-ssa-pre.c:2053
  135 | mpfr_sub1sp (mpfr_ptr a, mpfr_srcptr b, mpfr_srcptr c, mpfr_rnd_t
rnd_mode)
  | ^~~

[Bug tree-optimization/97808] New: ICE at -Os and above: in clean, at tree-ssa-pre.c:2053

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 97808
   Summary: ICE at -Os and above: in clean, at tree-ssa-pre.c:2053
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[514] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201112 (experimental) [master revision
7ea19dcafb8:c6f488d83fd:5d9ade39b8720b61cf63a8be181fb3b487f6ac5b] (GCC) 
[515] % 
[515] % gcctk -O1 -c small.c
[516] % 
[516] % gcctk -Os -c small.c
during GIMPLE pass: pre
small.c: In function ‘g’:
small.c:5:6: internal compiler error: in clean, at tree-ssa-pre.c:2053
5 | void g() {
  |  ^
0xed6c52 clean
../../gcc-trunk/gcc/tree-ssa-pre.c:2053
0xedced5 compute_antic
../../gcc-trunk/gcc/tree-ssa-pre.c:2539
0xedeb19 execute
../../gcc-trunk/gcc/tree-ssa-pre.c:4363
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[517] % 
[517] % cat small.c
int a, e, f;
volatile int b;
unsigned c, d;

void g() {
  int h = b;
  d = e;
  a = -(~h + d);
  c = d >> (b && f) ^ -~h;
}

[Bug middle-end/64711] Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations and memmov

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Eric Botcazou  ---
> as the comments says the check isn't correct but it might work for simple
> non-LTO cases.  Anybody willing to try?

But isn't LTO towards being the default these days?  If so, what's the point of
punishing every function for something that doesn't really work with LTO?

Cannot we clear the nothrow flag on the functions selectively instead?

[Bug target/97770] [ICELAKE]Missing vectorization for vpopcnt

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Hongtao.liu  ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558777.html

[Bug target/97807] ICE in output_move_double, at config/arm/arm.c:19689

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-11-12
 Status|UNCONFIRMED |NEW

[Bug target/97807] New: ICE in output_move_double, at config/arm/arm.c:19689

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97807
   Summary: ICE in output_move_double, at config/arm/arm.c:19689
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: ktkachov at gcc dot gnu.org, rdsandiford at googlemail dot 
com,
rearnsha at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: arm-linux-gnueabi

The following fails:

$ arm-linux-gnueabi-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/packed-aligned-1.c
-fno-forward-propagate -Os -mcpu=cortex-a17 -c
during RTL pass: final
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/packed-aligned-1.c:
In function ‘g’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/packed-aligned-1.c:11:1:
internal compiler error: in output_move_double, at config/arm/arm.c:19689
   11 | }
  | ^
0x600cfb output_move_double(rtx_def**, bool, int*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/config/arm/arm.c:19689
0x84b434 final_scan_insn_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/final.c:3039
0x84b8ab final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/final.c:3152
0x84bb84 final_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/final.c:2020
0x84c314 rest_of_handle_final
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/final.c:4658
0x84c314 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug testsuite/97803] c-c++-common/asan/pointer-compare-1.c assumes variable placement

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-11-12

--- Comment #2 from Martin Liška  ---
I can take care of this.

[Bug bootstrap/97806] [11 regression] bootstrap ICE starting with r11-4921

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Richard Biener  ---
OK, happens because topological sorting is not correct for the case where we
have multiple expressions for a value in the set.