[Bug sanitizer/98669] New: SIGSEGV on pc=0 in crypt() with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98669
Bug ID: 98669
Summary: SIGSEGV on pc=0 in crypt() with -fsanitize=address
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: marko.makela at mariadb dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
The following test program would crash when compiled with AddressSanitizer
instrumentation in GCC 10.2.1 for AMD64 on Debian GNU/Linux Sid (unstable):
cat > crypt.c << EOF
#include
#include
int main (int argc, char **argv)
{
puts(crypt(*argv, "salt"));
}
EOF
gcc -fsanitize=address crypt.c -lcrypt
./a.out
AddressSanitizer:DEADLYSIGNAL
=
==664877==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x bp 0x7fffb2b2b970 sp 0x7fffb2b2b958 T0)
==664877==Hint: pc points to the zero page.
==664877==The signal is caused by a READ memory access.
==664877==Hint: address points to the zero page.
#0 0x0 ()
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ()
==664877==ABORTING
If I compile the same without -fsanitize=address, or with clang-10 or clang-11,
the program will complete normally, outputting a line of text.
I traced the crash to the second (!) invocation of the function
__interceptor_crypt():
gdb a.out
break __interceptor_crypt
continue
display/i $pc
continue
nexti
nexti
...
The trace would end with the following:
1: x/i $pc
=> 0x7762ba4d <__interceptor_crypt(char*, char*)+125>:
jmp*0xdf55d(%rip)# 0x7770afb0
<_ZN14__interception10real_cryptE>
(gdb)
0x in ?? ()
[Bug target/98667] gcc generates endbr32 invalid opcode on -march=i486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98667 --- Comment #2 from Andrew Pinski --- Is this directly on a i486 box or VirtualBox? VirtualBox might have a bug.
[Bug target/98596] registers not reused on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98596 --- Comment #2 from Kito Cheng --- Few years ago, Monk and me has write a very detailed cost model for nds32 port, that way might able to fix the issue and further optimized for the code size and performance, but...it need lots time to fine tune and run benchmark again and again, so not sure when it can done. https://github.com/gcc-mirror/gcc/blob/master/gcc/config/nds32/nds32-cost.c
[Bug c++/98646] [11 Regression] A static_cast confuses -Wnonnull, causing false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98646
--- Comment #5 from Marek Polacek ---
A better one:
// PR c++/98646
// { dg-do compile }
// { dg-options "-Wnonnull" }
struct B {
void foo();
};
struct D : B {
void show();
};
void
D::show()
{
constexpr void *p = nullptr;
if (p)
static_cast(p)->foo();
}
[Bug c++/98646] [11 Regression] A static_cast confuses -Wnonnull, causing false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98646 --- Comment #4 from Marek Polacek --- The reduced testcase is unfortunately overreduced :(
[Bug c++/98646] [11 Regression] A static_cast confuses -Wnonnull, causing false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98646 --- Comment #3 from Marek Polacek --- Started with r11-1697.
[Bug ipa/98668] New: unused branch found in gcc/passes.c:do_per_function_toporder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98668
Bug ID: 98668
Summary: unused branch found in
gcc/passes.c:do_per_function_toporder
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: ashimida at linux dot alibaba.com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
during ipa passes execution, do_per_function_toporder is called to execute sub
passes in execute_ipa_pass_list (opt_pass *pass):
## passses.c
2988 void
2989 execute_ipa_pass_list (opt_pass *pass)
2990 {
2991 do
2992 {
2993 gcc_assert (!current_function_decl);
2994 gcc_assert (!cfun);
2995 gcc_assert (pass->type == SIMPLE_IPA_PASS || pass->type ==
IPA_PASS);
2996 if (execute_one_pass (pass) && pass->sub)
2997 {
2998 if (pass->sub->type == GIMPLE_PASS)
2999 {
3000 invoke_plugin_callbacks (PLUGIN_EARLY_GIMPLE_PASSES_START,
NULL);
3001 do_per_function_toporder ((void (*)(function *, void *))
3002 execute_pass_list,
3003 pass->sub);
..
## passes.c
1735 void
1736 do_per_function_toporder (void (*callback) (function *, void *data), void
*data)
1737 {
1738 int i;
1739
1740 if (current_function_decl)
1741 callback (cfun, data);
1742 else
1743 {
1744 hash_set removed_nodes;
when do_per_function_toporder is running, it should always have a context with
current_function_decl = cfunc = NULL, so codes in
do_per_function_toporder[1740,1742] should be deleted or changed to:
gcc_assert(!current_function_decl)
gcc_assert(!cfun)
(Or am I missing something?)
[Bug c++/98646] [11 Regression] A static_cast confuses -Wnonnull, causing false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98646
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek ---
// PR c++/98646
// { dg-do compile }
// { dg-options "-Wnonnull" }
struct B {
void foo();
};
struct D : B {
void show();
};
void D::show() { static_cast(0)->foo(); }
[Bug middle-end/98465] Bogus warning stringop-overread wuth -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98664 --- Comment #15 from Martin Sebor --- I created pr98664 to track just the -g interaction.
[Bug middle-end/98664] inconsistent --Wfree-nonheap-object for inlined calls to system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98664
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2021-01-14
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
The change below fixes the problem and lets both calls be diagnosed regardless
of -g:
index 02a7a56f0f9..a7464369d73 100644
--- a/gcc/tree-ssa-live.c
+++ b/gcc/tree-ssa-live.c
@@ -558,16 +558,13 @@ remove_unused_scope_block_p (tree scope, bool
in_ctor_dtor_block)
else if (!flag_auto_profile && debug_info_level == DINFO_LEVEL_NONE
&& !optinfo_wants_inlining_info_p ())
{
- /* Even for -g0 don't prune outer scopes from artificial
- functions, otherwise diagnostics using tree_nonartificial_location
- will not be emitted properly. */
+ /* Even for -g0 don't prune outer scopes from inlined functions,
+ otherwise late diagnostics from such functions will not be
+ emitted or suppressed properly. */
if (inlined_function_outer_scope_p (scope))
{
tree ao = BLOCK_ORIGIN (scope);
- if (ao
- && TREE_CODE (ao) == FUNCTION_DECL
- && DECL_DECLARED_INLINE_P (ao)
- && lookup_attribute ("artificial", DECL_ATTRIBUTES (ao)))
+ if (ao && TREE_CODE (ao) == FUNCTION_DECL)
unused = false;
}
}
[Bug c++/98667] gcc generates endbr32 invalid opcode on -march=i486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98667 --- Comment #1 from Matthew Whitehead --- Here is the full set of compiler flags used. readelf --string-dump='.GCC.command.line' /usr/lib/debug/$( which eix ).debug String dump of section '.GCC.command.line': [ 0] -I . [ 5] -I .. [ b] -D_GNU_SOURCE [19] -D HAVE_CONFIG_H [2a] -D SYSCONFDIR="/etc" [3f] -D LOCALEDIR="/usr/share/locale" [60] -D _FORTIFY_SOURCE=2 [75] various/drop_permissions.cc [91] -march=i486 [9d] -auxbase-strip various/drop_permissions.o [c7] -g [ca] -ggdb [d0] -O2 [d4] -fdata-sections [e4] -ffunction-sections [f8] -fcf-protection=full [ 10d] -fstack-clash-protection [ 126] -frecord-gcc-switches [ 13c] eixTk/compare.cc [ 14d] -auxbase-strip eixTk/compare.o [ 16c] eixTk/formated.cc [ 17e] -auxbase-strip eixTk/formated.o [ 19e] eixTk/stringutils.cc [ 1b3] -auxbase-strip eixTk/stringutils.o [ 1d6] eixTk/ansicolor.cc [ 1e9] -auxbase-strip eixTk/ansicolor.o [ 20a] eixTk/argsreader.cc [ 21e] -auxbase-strip eixTk/argsreader.o [ 240] eixTk/parseerror.cc [ 254] -auxbase-strip eixTk/parseerror.o [ 276] eixTk/regexp.cc [ 286] -auxbase-strip eixTk/regexp.o [ 2a4] eixTk/sysutils.cc [ 2b6] -auxbase-strip eixTk/sysutils.o [ 2d6] eixTk/filenames.cc [ 2e9] -auxbase-strip eixTk/filenames.o [ 30a] eixTk/utils.cc [ 319] -auxbase-strip eixTk/utils.o [ 336] eixTk/varsreader.cc [ 34a] -auxbase-strip eixTk/varsreader.o [ 36c] database/io.cc [ 37b] -auxbase-strip database/io.o [ 398] database/io_header.cc [ 3ae] -auxbase-strip database/io_header.o [ 3d2] database/header.cc [ 3e5] -auxbase-strip database/header.o [ 406] database/header_portage.cc [ 421] -auxbase-strip database/header_portage.o [ 44a] database/io_portage.cc [ 461] -auxbase-strip database/io_portage.o [ 486] database/package_reader.cc [ 4a1] -auxbase-strip database/package_reader.o [ 4ca] portage/conf/portagesettings.cc [ 4ea] -auxbase-strip portage/conf/portagesettings.o [ 518] portage/conf/cascadingprofile.cc [ 539] -auxbase-strip portage/conf/cascadingprofile.o [ 568] eixTk/stringlist.cc [ 57c] -auxbase-strip eixTk/stringlist.o [ 59e] portage/mask.cc [ 5ae] -auxbase-strip portage/mask.o [ 5cc] portage/mask_list.cc [ 5e1] -auxbase-strip portage/mask_list.o [ 604] portage/depend.cc [ 616] -auxbase-strip portage/depend.o [ 636] portage/basicversion.cc [ 64e] -auxbase-strip portage/basicversion.o [ 674] portage/eapi.cc [ 684] -auxbase-strip portage/eapi.o [ 6a2] portage/extendedversion.cc [ 6bd] -auxbase-strip portage/extendedversion.o [ 6e6] portage/extendedversion_bin.cc [ 705] -auxbase-strip portage/extendedversion_bin.o [ 732] portage/instversion.cc [ 749] -auxbase-strip portage/instversion.o [ 76e] portage/package.cc [ 781] -auxbase-strip portage/package.o [ 7a2] portage/package_best.cc [ 7ba] -auxbase-strip portage/package_best.o [ 7e0] portage/packagesets.cc [ 7f7] -auxbase-strip portage/packagesets.o [ 81c] portage/vardbpkg.cc [ 830] -auxbase-strip portage/vardbpkg.o [ 852] portage/packagetree.cc [ 869] -auxbase-strip portage/packagetree.o [ 88e] portage/keywords.cc [ 8a2] -auxbase-strip portage/keywords.o [ 8c4] portage/overlay_bin.cc [ 8db] -auxbase-strip portage/overlay_bin.o [ 900] portage/overlay.cc [ 913] -auxbase-strip portage/overlay.o [ 934] portage/set_stability.cc [ 94d] -auxbase-strip portage/set_stability.o [ 974] portage/version.cc [ 987] -auxbase-strip portage/version.o [ 9a8] eixrc/eixrc.cc [ 9b7] -auxbase-strip eixrc/eixrc.o [ 9d4] eixrc/global.cc [ 9e4] -auxbase-strip eixrc/global.o [ a02] eixrc/globals.cc [ a13] -auxbase-strip eixrc/globals.o [ a32] eixrc/eixrc_portage.cc [ a49] -auxbase-strip eixrc/eixrc_portage.o [ a6e] eixTk/outputstring.cc [ a84] -auxbase-strip eixTk/outputstring.o [ aa8] eixTk/stringlist_output.cc [ ac3] -auxbase-strip eixTk/stringlist_output.o [ aec] portage/version_output.cc [ b06] -auxbase-strip portage/version_output.o [ b2e] output/formatstring.cc [ b45] -auxbase-strip output/formatstring.o [ b6a] output/formatstring-print.cc [ b87] -auxbase-strip output/formatstring-print.o [ bb2] eix.cc [ bb9] -auxbase-strip eix.o [ bce] various/cli.cc [ bdd] -auxbase-strip various/cli.o [ bfa] output/print-proto.cc [ c10] -auxbase-strip output/print-proto.o [ c34] output/print-xml.cc [ c48] -auxbase-strip output/print-xml.o [ c6a] search/levenshtein.cc [ c80] -auxbase-strip search/levenshtein.o [ ca4] search/algorithms.cc
[Bug c++/98667] New: gcc generates endbr32 invalid opcode on -march=i486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98667
Bug ID: 98667
Summary: gcc generates endbr32 invalid opcode on -march=i486
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tedheadster at gmail dot com
Target Milestone: ---
Compiling the 'eix' program with gcc 9.3.0 and the '-march=i486' generated an
'endbr32' opcode. This is an undefined opcode on an i486.
# /usr/bin/gdb /usr/bin/eix
GNU gdb (Gentoo 10.1 vanilla) 10.1
...
Reading symbols from /usr/bin/eix...
Reading symbols from /usr/lib/debug//usr/bin/eix.debug...
(gdb) run
Starting program: /usr/bin/eix
Program received signal SIGILL, Illegal instruction.
_GLOBAL__sub_I_spaces () at eixTk/stringutils.cc:686
686 }
(gdb) disassemble _GLOBAL__sub_I_spaces
Dump of assembler code for function _GLOBAL__sub_I_spaces():
=> 0x004208e0 <+0>: endbr32
0x004208e4 <+4>: push %esi
0x004208e5 <+5>: push %ebx
0x004208e6 <+6>: sub $0xc,%esp
0x004208e9 <+9>: call 0x420d30 <__x86.get_pc_thunk.bx>
0x004208ee <+14>: add $0x17e712,%ebx
0x0042091e <+62>: add $0x14,%esp
0x00420921 <+65>: pop %ebx
0x00420922 <+66>: pop %esi
0x00420923 <+67>: ret
(gdb) list
681 if(likely(isutf8firstgyte(t[i]))) {
682 ++len;
683 }
684 }
685 return len;
686 }
[Bug c++/98660] -Wold-style-cast should not warn on casts that look like (decltype(x))(x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98660 Ivan Sorokin changed: What|Removed |Added CC||vanyacpp at gmail dot com --- Comment #1 from Ivan Sorokin --- I'm not a GCC developer, but I'm just curious. Why the use of C-style cast is required here? Could you use static_cast instead? I mean instead of `(decltype(x))(x)` using `static_cast(x)`? Perhaps wrapping it in some macro in order to not duplicate `x` twice.
[Bug target/98596] registers not reused on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98596 Jim Wilson changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-14 CC||wilson at gcc dot gnu.org --- Comment #1 from Jim Wilson --- Part of the problem seems to be the use of volatile, as we disable optimizations inside volatile operations, and both constants are used inside volatile operations. But a bigger issue seems to be how we calculate constant costs. In riscv_rtx_costs we have /* If the constant is likely to be stored in a GPR, SETs of single-insn constants are as cheap as register sets; we never want to CSE them. */ if (cost == 1 && outer_code == SET) *total = 0; which tells the compiler that constants are cheaper than registers. If I change that to "*total = 1;" then the two constants get optimized. Changing this cost means we will likely extend register lifetimes and increase register pressure, which may reduce performance in some applications. We would need a lot of tersting to see what happens. We are already computing a cost of 0 for constants in the arithmetic immediate range, so setting costs to 0 here seems unnecessary, but it is hard to predict what might happen with this change. There might be something else I'm missing here.
[Bug other/98663] gcc generates endless loop at -O2 or greater depending on order of testExpression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98663 --- Comment #5 from charliepdts at gmx dot at --- Hi Jakub, thanks for the detailed description and the insights as to the assumptions that the compiler uses when optimizing code like this.
[Bug c++/98665] lvalue ref lifetime extension missing for via sub-object of temporary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98665 Jeff Gilbert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jeff Gilbert --- Thanks for the clarification!
[Bug c++/98665] lvalue ref lifetime extension missing for via sub-object of temporary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98665 --- Comment #4 from Jonathan Wakely --- Right.
[Bug c++/98665] lvalue ref lifetime extension missing for via sub-object of temporary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98665 --- Comment #3 from Jeff Gilbert --- Ok, but this is ok, right? const auto& i2 = f().i;
[Bug c++/98665] lvalue ref lifetime extension missing for via sub-object of temporary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98665
--- Comment #2 from Jonathan Wakely ---
If you make everything constexpr then Clang will correctly diagnose the UB, but
GCC fails to:
constexpr int IntSize() { return sizeof(int); }
#include
// -
template
class Maybe {
bool mIsSome = false;
T mVal = {};
public:
Maybe() = default;
constexpr Maybe(const T& rhs) : mIsSome(true), mVal(rhs) {}
constexpr T& operator*() {
assert(mIsSome);
return mVal;
}
};
// -
struct Int {
int val = {};
Int() = default;
constexpr Int(int x) : val(x) {}
};
struct Even : public Int {
public:
constexpr static Maybe From(const Int x) {
if (x.val & 1) return {};
return Even{x.val};
}
Even() = default;
private:
constexpr Even(int x) : Int(x) {
assert((val & 1) == 0);
}
};
constexpr int Oops(const Int i) {
const auto& e = *Even::From(i); // lvalue ref lifetime extension of
sub-object
// of temporary?
return e.val + 9; // or UB access?
}
int main()
{
constexpr int i = Oops({});
}
GCC should not compile this.
[Bug fortran/89204] -floop-interchange has no effect on Fortran code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89204 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #4) > > Works for me > > What is working for you? > > With the original fortran test I get > > % gfc pr89204.f90 -O2 -floop-interchange > % time ./a.out > 35.970u 0.081s 0:36.76 98.0% 0+0k 0+0io 0pf+0w > > If I move the 'i' do loop inside the nested loops I get > > % gfc pr89204_db.f90 -O2 > % time ./a.out > 8.124u 0.025s 0:08.76 92.9% 0+0k 0+0io 0pf+0w You're wasting your time. Chinoune closed this and other PRs that s/he submitted because of a temper tantrum. S/He's upset that https://gcc.gnu.org/pipermail/gcc-bugs/2021-January/724765.html was closed as INVALID because the behavior documented in the manual does not meet his/her expectations. S/He refuses to accept that gfortran has selected processor-dependent behavior that does is different than Intel Fortran. Note Intel Fortran documents it choice, but does not conform to its own documentation. Just open a new PR with a Depends On reference to this PR.
[Bug other/98663] gcc generates endless loop at -O2 or greater depending on order of testExpression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98663 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- We have a warning but only if the loop doesn't have multiple exits. In your case it has multiple exits and warning on it would be only a false positive for perfectly valid code that would just assume that read[x] would be 0x for at least one i in between 0 and 449 inclusive. Compiler really doesn't have an intention to punish users and break their code, but just assumes the code doesn't trigger undefined behavior. In particular in this case, in some places it computes that the maximum number of iterations of the loop is bounded by not invoking UB with read[450], some other pass will compute value ranges of the iteration and yet another piece of code will determine that the i < 450 condition is always true due to the limited range and thus can be optimized away.
[Bug c++/98665] lvalue ref lifetime extension missing for via sub-object of temporary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98665
--- Comment #1 from Jonathan Wakely ---
Not a bug. This is equivalent to:
struct X { int i; };
X f() { return { 0 }; }
const int& g(const X& x) { return x.i; }
int main()
{
const auto& i = g(f());
}
The temporary's lifetime is not extended, because the reference doesn't bind
directly to it.
[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519 --- Comment #17 from Segher Boessenkool --- (What i was referring to in Comment 4 was asm_operand_ok in recog.c -- it may need some surgery if we need to hook into that).
[Bug c++/98545] [11 Regression] ICE in write_expression, at cp/mangle.c:3352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98545 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug other/98663] gcc generates endless loop at -O2 or greater depending on order of testExpression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98663 --- Comment #3 from charliepdts at gmx dot at --- While I appreciate the anything can happen, what surprised us was the lack of any kind of warning. Does the compiler not notice the access outside the array in this case? background: we are working with a rather large codebase here for an embedded target which unfortunately does not play nice with gdb. The tracking down of this behaviour took rather long. A warning could have helped us find and eliminate this problem in our code much sooner.
[Bug c++/98231] [11 Regression] bogus error: no match for ‘operator<<’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98231 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/98231] [11 Regression] bogus error: no match for ‘operator<<’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98231 --- Comment #2 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:796ead19f85372e59217c9888db688a2fe11b54f commit r11-6652-g796ead19f85372e59217c9888db688a2fe11b54f Author: Marek Polacek Date: Wed Jan 13 11:09:14 2021 -0500 c++: Failure to lookup using-decl name [PR98231] In r11-4690 we removed the call to finish_nonmember_using_decl in tsubst_expr/DECL_EXPR in the USING_DECL block. This was done not to perform name lookup twice for a non-dependent using-decl, which sounds sensible. However, finish_nonmember_using_decl also pushes the decl's bindings which we still have to do so that we can find the USING_DECL's name later. In this case, we've got a USING_DECL N::operator<< that we are tsubstituting. We already looked it up while parsing the template "foo", and lookup_using_decl stashed the OVERLOAD it found into USING_DECL_DECLS. Now we just have to update the IDENTIFIER_BINDING of the identifier for operator<< with the overload the name is bound to. I didn't want to export push_local_binding so I've introduced a new wrapper. gcc/cp/ChangeLog: PR c++/98231 * name-lookup.c (push_using_decl_bindings): New. * name-lookup.h (push_using_decl_bindings): Declare. * pt.c (tsubst_expr): Call push_using_decl_bindings. gcc/testsuite/ChangeLog: PR c++/98231 * g++.dg/lookup/using63.C: New test.
[Bug c++/98665] New: lvalue ref lifetime extension missing for via sub-object of temporary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98665
Bug ID: 98665
Summary: lvalue ref lifetime extension missing for via
sub-object of temporary expression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jgilbert at mozilla dot com
Target Milestone: ---
This is like bug 81420.
Taking an lvalue ref of a sub-object expression should extend the lifetimes of
the needed sub-objects to the lifetime of the lvalue ref.
I believe that apples to this case, and clang and msvc seem to compile it that
way. (which doesn't mean it's not UB, of course)
It's possible that this example is past some complexity limit where the lvalue
ref rule becomes impossible to handle, but this seems suspect enough
(especially given bug 81420 which we've had trouble with before) that I'm
filing this bug.
In the example below, GCC compile Oops() into `return 9`:
https://godbolt.org/z/MYPhaW
> #include
>
> // -
>
> template
> class Maybe {
> bool mIsSome = false;
> T mVal = {};
>
> public:
> Maybe() = default;
> Maybe(const T& rhs) : mIsSome(true), mVal(rhs) {}
>
> T& operator*() {
> assert(mIsSome);
> return mVal;
> }
> };
>
> // -
>
> struct Int {
> int val = {};
>
> Int() = default;
> Int(int x) : val(x) {}
> };
>
> struct Even : public Int {
> public:
> static Maybe From(const Int x) {
> if (x.val & 1) return {};
> return Even{x.val};
> }
>
> Even() = default;
> private:
> Even(int x) : Int(x) {
> assert((val & 1) == 0);
> }
> };
>
> // -
>
> int Oops(const Int i) {
> const auto& e = *Even::From(i); // lvalue ref lifetime extension of
> sub-object
> // of temporary?
> return e.val + 9; // or UB access?
> }
[Bug analyzer/98599] fatal error: Cgraph edge statement index out of range with -Os -flto -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599 David Malcolm changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #9 from David Malcolm --- Candidate patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563416.html
[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519 --- Comment #16 from Segher Boessenkool --- No, this cannot be fixed in this hook, or in any other hook. The compiler can never see *at all* what instructions there are, the template is just a piece of text to it (there could be assembler macros in play, if you need to see a practical reason). We just need new constraints, as Bill and Peter agree.
[Bug other/98663] gcc generates endless loop at -O2 or greater depending on order of testExpression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98663 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Accessing outside the bounds of an array is undefined behavior so anything can happen.
[Bug fortran/98661] Valgrind errors during error recovery of invalid derived type declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2021-January/055595.html
[Bug middle-end/98664] New: inconsistent --Wfree-nonheap-object for inlined calls to system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98664
Bug ID: 98664
Summary: inconsistent --Wfree-nonheap-object for inlined calls
to system headers
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
-Wfree-nonheap-object (as well as -Wmismatched-new-delete and
-Wmismatched-dealloc) should be issued for invalid calls to allocation and
deallocation functions made in system headers and inlined into user code (see
pr57111 comment 16). The test case below shows this doesn't work consistently.
When the program is compiled without -g only one invalid call is diagnosed.
But when it's compiled with -g both are.
This bug captures the subset related to the -g inconsistency discussed in
pr98465.
Without -g:
$ cat t.C && gcc -O2 -S -Wall -Wextra t.C
# 1 "t.h" 1 3
struct S
{
void *p;
void f0 (void *q) { p = q; }
void f1 (void *q) { f0 (q); }
void g0 (void) { __builtin_free (p); }
void g1 (void) { g0 (); }
};
# 1 "t.C"
int x;
__attribute__ ((noipa)) void f0 (struct S *p)
{
p->f0 ();
p->g0 ();
}
__attribute__ ((noipa)) void f1 (struct S *p)
{
p->f1 ();
p->g1 ();
}
In file included from t.C:1:
In member function ‘void S::g0()’,
inlined from ‘void f0(S*)’ at t.C:7:9:
t.h:8:35: warning: ‘void __builtin_free(void*)’ called on unallocated object
‘x’ [-Wfree-nonheap-object]
In file included from t.C:1:
t.C: In function ‘void f0(S*)’:
t.C:2:5: note: declared here
2 |
| ^
With -g:
$ gcc -O2 -S -Wall -Wextra -g t.C
In file included from t.C:1:
In member function ‘void S::g0()’,
inlined from ‘void f0(S*)’ at t.C:7:9:
t.h:8:35: warning: ‘void __builtin_free(void*)’ called on unallocated object
‘x’ [-Wfree-nonheap-object]
In file included from t.C:1:
t.C: In function ‘void f0(S*)’:
t.C:2:5: note: declared here
2 |
| ^
In file included from t.C:1:
In member function ‘void S::g0()’,
inlined from ‘void S::g1()’ at t.h:9:23,
inlined from ‘void f1(S*)’ at t.C:13:9:
t.h:8:35: warning: ‘void __builtin_free(void*)’ called on unallocated object
‘x’ [-Wfree-nonheap-object]
In file included from t.C:1:
t.C: In function ‘void f1(S*)’:
t.C:2:5: note: declared here
2 |
| ^
[Bug c++/98545] [11 Regression] ICE in write_expression, at cp/mangle.c:3352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98545 --- Comment #3 from Marek Polacek --- (In reply to Marek Polacek from comment #2) > but I need to figure out how to test this. [[gnu::used]] to actually emit the function.
[Bug other/98663] gcc generates endless loop at -O2 or greater depending on order of testExpression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98663 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #1 from Dávid Bolvanský --- Compiler can do anything if there is UB in the code.
[Bug other/98663] New: gcc generates endless loop at -O2 or greater depending on order of testExpression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98663
Bug ID: 98663
Summary: gcc generates endless loop at -O2 or greater depending
on order of testExpression
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: charliepdts at gmx dot at
Target Milestone: ---
Created attachment 49961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49961=edit
minimal example in testcase_bad_for
While porting legacy code which worked with v4.1.1 to v4.9.1 we discovered gcc
producing an endless loop.
Our v4.9.1 configured with: --enable-languages=c,c++ --with-float=soft
--enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp
--disable-libquadmath --disable-libquadmath-support --disable-libsanitizer
--with-gmp=... --with-mpfr=... --with-mpc=... --with-isl=... --with-cloog=...
--with-libelf=... --enable-threads=posix --disable-nls --disable-multilib
--enable-c99 --enable-long-long
gcc version:
We also tried this on various linux distributions with gcc versions greater
v4.6.4 up to v9 and they all produced endless loops with this code.
gcc targets:
This appears independent of the target architecture as powerpc, arm and x86_64
targets all displayed the same behaviour.
Compilation options:
gcc -Wall -Wextra -Os -o test4 test4.c
Compilation output:
none
mini-snippet, test4.i included:
unsigned short read[450];
for (i = 0 ; (read[i] != 0x) && (i < 450) ; i++) {...}
The assembly code generated does the first check but optimises out the second.
Now while I agree that the above code is not really nice (legacy...) with the
last loop check being an out of bounds read access, 'gcc -Wall -Wextra' does
not even produce an array bounds warning.
With -O1 correct code is produced, no array bounds warning though.
With -O2 and -fno-aggressive-loop-optimizations correct code is produced.
Otherwise -O2, -Os and -O3 all produce endless loops.
turning the checks in the testExpression around as expected produces correct
code
for (i = 0 ; (i < 450) && (read[i] != 0x) ; i++)
similar while loops produce the same endless loops
while ((read[i] != 0x) && (i < 450))
{
...
i++;
}
[Bug fortran/98661] Valgrind errors during error recovery of invalid derived type declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661
--- Comment #2 from anlauf at gcc dot gnu.org ---
This has nothing to do with character at all. Same issue with:
program p
implicit none
type t
integer, allocatable :: x(n) ! { dg-error "must have a deferred shape" }
end type
end
I am regtesting the following patch:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 3929ddff849..d1ba20cc3c0 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -14723,6 +14735,9 @@ resolve_component (gfc_component *c, gfc_symbol *sym)
&& sym != c->ts.u.derived)
add_dt_to_dt_list (c->ts.u.derived);
+ if (c->as && c->as->type != AS_DEFERRED && c->attr.allocatable)
+return false;
+
if (!gfc_resolve_array_spec (c->as,
!(c->attr.pointer || c->attr.proc_pointer
|| c->attr.allocatable)))
[Bug c++/98545] [11 Regression] ICE in write_expression, at cp/mangle.c:3352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98545
--- Comment #2 from Marek Polacek ---
Candidate fix:
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -3349,7 +3349,8 @@ write_expression (tree expr)
else if (dependent_name (expr))
{
tree name = dependent_name (expr);
- gcc_assert (!IDENTIFIER_ANY_OP_P (name));
+ if (IDENTIFIER_ANY_OP_P (name))
+ write_string ("on");
write_unqualified_id (name);
}
else
but I need to figure out how to test this.
[Bug c++/98662] New: checking ICE in friend_accessible_p since r227023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98662
Bug ID: 98662
Summary: checking ICE in friend_accessible_p since r227023
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat testcase.C
template
struct S {
friend int f(S) {
S y;
(void) y.i;
(void) y.j;
return 0;
}
private:
int i;
protected:
int j;
};
extern S s;
int a = f(s);
$ g++ testcase.C
testcase.C: In instantiation of ‘int f(S)’:
testcase.C:18:12: required from here
testcase.C:8:14: internal compiler error: in friend_accessible_p, at
cp/search.c:732
8 | (void) y.j; // { dg-error "protected" }
|~~^
0x6c4b3c friend_accessible_p
/home/patrick/gcc/gcc/cp/search.c:732
0xad439d friend_accessible_p
/home/patrick/gcc/gcc/cp/search.c:724
0xad4662 dfs_accessible_post
/home/patrick/gcc/gcc/cp/search.c:792
0xad2762 dfs_walk_once_accessible_r
/home/patrick/gcc/gcc/cp/search.c:1588
0xad3012 accessible_p(tree_node*, tree_node*, bool)
/home/patrick/gcc/gcc/cp/search.c:889
0xad54f3 enforce_access
/home/patrick/gcc/gcc/cp/semantics.c:314
0xad5931 perform_or_defer_access_check(tree_node*, tree_node*, tree_node*, int,
access_failure_info*)
/home/patrick/gcc/gcc/cp/semantics.c:403
0xad1995 lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
/home/patrick/gcc/gcc/cp/search.c:1176
0xb2bc86 finish_class_member_access_expr(cp_expr, tree_node*, bool, int)
/home/patrick/gcc/gcc/cp/typeck.c:3188
...
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 96691, which changed state. Bug 96691 Summary: Failure to optimize bitwise not+or+xor with constants to and+xor with bitwise not-ed constants https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96691 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/96691] Failure to optimize bitwise not+or+xor with constants to and+xor with bitwise not-ed constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96691 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug fortran/98661] Valgrind errors during error recovery of invalid derived type declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-13 Blocks||86656, 89891 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I don't see the need to open a new PR for that. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 [Bug 86656] [meta-bug] Issues found with -fsanitize=address https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89891 [Bug 89891] [meta-bug] Accessing memory in rejected statements or expressions
[Bug fortran/89891] [meta-bug] Accessing memory in rejected statements or expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89891 Bug 89891 depends on bug 78746, which changed state. Bug 78746 Summary: charlen_03, charlen_10 ICE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/78746] charlen_03, charlen_10 ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #31 from anlauf at gcc dot gnu.org --- The valgrind issues with error-recovery with charlen_03 has been moved to PR98661, and there is no longer an ICE as reported here. To avoid further cluttering of the present PR, please add further comments there.
[Bug other/86656] [meta-bug] Issues found with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 Bug 86656 depends on bug 78746, which changed state. Bug 78746 Summary: charlen_03, charlen_10 ICE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/98661] Valgrind errors during error recovery of invalid derived type declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P4
[Bug fortran/98661] New: Valgrind errors during error recovery of invalid derived type declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661
Bug ID: 98661
Summary: Valgrind errors during error recovery of invalid
derived type declarations
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gcc dot gnu.org
Target Milestone: ---
The following invalid code exhibits valgrind issues during error recovery
(based on charlen_03.f90 which was removed from the testsuite, see PR78746)
program p
implicit none
type t
character(:), allocatable :: x(n) ! { dg-error "must have a deferred
shape" }
end type
end
! { dg-excess-errors "must be of INTEGER type" }
and similarly with "implicit none" commented out.
Simpler versions, with "character(:)" replaced by "character(1)",
produce similar valgrind output, so may be easier to debug.
[Bug middle-end/98465] Bogus warning stringop-overread wuth -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465
--- Comment #14 from Martin Sebor ---
Smallish test case independent of libstdc++ that reproduces both the false
positive (due to the missing aliasing constraint) and its absence (due to a
bug/limitation in tree_inlined_location). With -Wsystem-headers GCC issues two
instances of the false positive, one for f() and the other for g():
$ cat pr98465.C && gcc -O2 -S -Wall -Wextra pr98465.C
# 1 "pr98465.h" 1 3
typedef __SIZE_TYPE__size_type;
typedef __UINTPTR_TYPE__ uintptr_t;
struct S {
char *dta;
size_type cap, siz;
bool _M_disjunct (const char *s) const {
return ((uintptr_t)s < (uintptr_t)dta
|| (uintptr_t)dta + siz < (uintptr_t)s);
}
void assign (const char *s, size_type n) {
assign2 (s, n);
}
void assign2 (const char *s, size_type n) {
_M_replace (0, siz, s, n);
}
void _M_replace (size_type pos, size_type len1, const char* s,
const size_type len2) {
const size_type old_size = siz;
const size_type new_size = old_size + len2 - len1;
if (new_size <= cap)
{
char *p = dta + pos;
const size_type how_much = old_size - pos - len1;
if (_M_disjunct (s))
{
if (how_much && len1 != len2)
__builtin_memmove (p + len2, p + len1, how_much);
if (len2)
__builtin_memcpy (p, s, len2);
}
else
{
if (len2 && len2 <= len1)
__builtin_memmove (p, s, len2);
if (how_much && len1 != len2)
__builtin_memmove (p + len2, p + len1, how_much);
if (len2 > len1)
{
if (s + len2 <= p + len1)
__builtin_memmove (p, s, len2);
else if (s >= p + len1)
__builtin_memcpy (p, s + len2 - len1, len2);
else
{
const size_type nleft = (p + len1) - s;
__builtin_memmove (p, s, nleft);
__builtin_memcpy (p + nleft, p + len2,
len2 - nleft);
}
}
}
}
}
};
# 1 "pr98465.C"
const char a[] = { 1, 2 };
void f (S )
{
s.assign (a, 2); // no warning
}
const char b[] = { 2, 3 };
void g (S )
{
s.assign2 (b, 2); // bogus -Wstringop-overread
}
In file included from pr98465.C:1:
In member function ‘void S::_M_replace(size_type, size_type, const char*,
size_type)’,
inlined from ‘void S::assign2(const char*, size_type)’ at pr98465.h:19:16,
inlined from ‘void g(S&)’ at pr98465.C:13:13:
pr98465.h:50:24: warning: ‘void* __builtin_memcpy(void*, const void*, long
unsigned int)’ reading 2 bytes from a region of size 1 [-Wstringop-overread]
In file included from pr98465.C:1:
pr98465.C: In function ‘void g(S&)’:
pr98465.C:9:12: note: at offset [1, 2] into source object ‘b’ of size 2
9 |
|^
[Bug middle-end/98465] Bogus warning stringop-overread wuth -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 --- Comment #13 from Jakub Jelinek --- Note, it is important to be able for -g0 to be able to optimize as many BLOCKs as possible especially for LTO memory consumptions, so it should be just the BLOCKs at inline boundaries that could be significant to diagnostics.
[Bug middle-end/98465] Bogus warning stringop-overread wuth -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 --- Comment #12 from Martin Sebor --- (In reply to Jeffrey A. Law from comment #10) > What about fixing the -g interaction? Much like how -g shouldn't affect > code generation, it probably shouldn't be affecting warnings like this. > > There may be more we can/should do here, but that seems like a good place to > start. Agreed, I'm looking into that too. Fixing it won't avoid the warning though, just make it more consistent (see comment #4).
[Bug tree-optimization/96691] Failure to optimize bitwise not+or+xor with constants to and+xor with bitwise not-ed constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96691 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8fc183ccd0628465205b8a88c29ab69bfe74a08a commit r11-6651-g8fc183ccd0628465205b8a88c29ab69bfe74a08a Author: Jakub Jelinek Date: Wed Jan 13 19:54:49 2021 +0100 match.pd: Fold (~X | C) ^ D into (X | C) ^ (~D ^ C) if (~D ^ C) can be simplified [PR96691] These simplifications are only simplifications if the (~D ^ C) or (D ^ C) expressions fold into gimple vals, but in that case they decrease number of operations by 1. 2021-01-13 Jakub Jelinek PR tree-optimization/96691 * match.pd ((~X | C) ^ D -> (X | C) ^ (~D ^ C), (~X & C) ^ D -> (X & C) ^ (D ^ C)): New simplifications if (~D ^ C) or (D ^ C) can be simplified. * gcc.dg/tree-ssa/pr96691.c: New test.
[Bug middle-end/98465] Bogus warning stringop-overread wuth -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- Yeah, -g shouldn't affect which warnings are emitted either. If you now all newly rely on some BLOCKs being preserved, then you actually need to make sure they are not thrown away - see tree-ssa-live.c.
[Bug middle-end/98465] Bogus warning stringop-overread wuth -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #10 from Jeffrey A. Law --- What about fixing the -g interaction? Much like how -g shouldn't affect code generation, it probably shouldn't be affecting warnings like this. There may be more we can/should do here, but that seems like a good place to start.
[Bug analyzer/98599] fatal error: Cgraph edge statement index out of range with -Os -flto -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599 --- Comment #8 from David Malcolm --- Saving and restoring the uids fixes the issue, so I'm working on a patch to the analyzer pass to do that.
[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 --- Comment #12 from Matheus Izvekov --- Thank you!!!
[Bug middle-end/98465] Bogus warning stringop-overread wuth -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|--- |11.0 Priority|P3 |P2 Keywords||alias Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #9 from Martin Sebor --- Bumping up Priority to 2 since this is causing Fedora build failures (with -Werror) in a number of packages. I can't think of a better near term fix/workaround (for GCC 11) than to revert the change enabling the -Wstringop-xxx warnings for memcpy/memmove calls in system headers inlined into user code. This won't eliminate the warning completely, just suppress it when -Wno-system-headers is in effect (which is by default), and restore things to their pre-GCC 11 status. My idea for a longer term solution is to add some source-level annotation to containers like std::string to either let GCC eliminate the unreachable code altogether, or let the warning determine the code is, in fact, unreachable. For reference, here's a brief exchange we had on this subject: https://gcc.gnu.org/pipermail/gcc/2021-January/234641.html
[Bug tree-optimization/96688] Failure to optimize shift-right/add+bitwise not of constant to avoid bitwise not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96688 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 49960 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49960=edit gcc11-pr96688.patch Untested fix for the right shifts.
[Bug c++/98660] New: -Wold-style-cast should not warn on casts that look like (decltype(x))(x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98660
Bug ID: 98660
Summary: -Wold-style-cast should not warn on casts that look
like (decltype(x))(x)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gasper.azman at gmail dot com
Target Milestone: ---
Dear GCC wizards,
Recently, the use of std::forward has been idiomatically replaced by the
following:
```
template
void george(T&& x) {
john((T&&)x); // means std::forward(x)
}
```
Casting an `x` to `decltype(x)` is far shorter and faster to compile (which
matters since it's done in unevaluated contexts A LOT). For an example, observe
the usage in libunifex, the in-progress research implementation of the
executors proposal:
https://github.com/facebookexperimental/libunifex/blob/master/include/unifex/tag_invoke.hpp
Unfortunately, the only real way to combine this fairly important exception to
the general rules of "no c-style casts" is to disable -Wold-style-cast.
It would be a great benefit if I could leave that warning enabled, and sleep
soundly in the knowledge I didn't mistype the forwarding expression if gcc
checked for me that the type I'm casting to is, in fact, `decltype(x)`, and
complain otherwise.
Please consider this refinement for a future release of GCC.
Thank you.
[Bug target/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 --- Comment #19 from Paul Sokolovsky --- Vladimir Makarov, Przemyslaw Wirkus: Thanks looking into this issue and fixing it!
[Bug c++/98231] [11 Regression] bogus error: no match for ‘operator<<’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98231 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug tree-optimization/96688] Failure to optimize shift-right/add+bitwise not of constant to avoid bitwise not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96688 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The #c1 case is optimized since r11-5958-g0bd675183d94e6bca100c3aaaf87ee9676fb3c26 aka PR96685 changes.
[Bug c/98658] Loop idiom recognization for memcpy/memmove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98658 --- Comment #3 from Dávid Bolvanský --- Yes, runtime check.
[Bug fortran/78746] charlen_03, charlen_10 ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746 --- Comment #30 from anlauf at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #29) > > There's no testcase named "pr78746.f90" in the testsuite. > > Ideed! My prx.f90 are in the test suite only when they are fixed. > > Now my "pr78746.f90" is exactly charlen_03.f90. ... which was removed by Steve. We're running in circles, so please open a new pr.
[Bug c++/98463] [11 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:5491 by r11-2720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98463 --- Comment #8 from Jakub Jelinek --- With the patch for C++14 and older the problem is that the empty base has no FIELD_DECL in the RECORD_TYPE at all, so it then doesn't find anything. So for the empty_base && lval case it might be better to return some tree that would make it clear to the caller that the code is valid but that it shouldn't really store anything into it. But still, for C++17 and onwards, we shouldn't be setting empty_base for the lval case if we can find the FIELD_DECL for it (so perhaps for lval move the is_empty_class check to the end) and otherwise figure out what to return. A freshly created VAR_DECL, or one that is cached (same VAR_DECL for the same type), something else?
[Bug tree-optimization/98597] [11 Regression] ICE in print_mem_ref since r11-6508-gabb1b6058c09a7c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98597 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Martin Sebor --- The ICE has been fixed. Please open a new bug to track improvements that are unrelated to the ICE. Or, if you want to repurpose this bug for your own changes assign it to yourself.
[Bug fortran/78746] charlen_03, charlen_10 ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746 --- Comment #29 from Dominique d'Humieres --- > There's no testcase named "pr78746.f90" in the testsuite. Ideed! My prx.f90 are in the test suite only when they are fixed. Now my "pr78746.f90" is exactly charlen_03.f90.
[Bug c++/98231] [11 Regression] bogus error: no match for ‘operator<<’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98231
--- Comment #1 from Marek Polacek ---
This seems to work...
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -9279,4 +9279,14 @@ push_operator_bindings ()
}
}
+/* Wrapper around push_local_binding to push the bindings for
+ a non-member USING_DECL that were found during template parsing. */
+
+void
+push_using_decl_bindings (tree decl)
+{
+ push_local_binding (DECL_NAME (decl), USING_DECL_DECLS (decl),
+ /*using*/true);
+}
+
#include "gt-cp-name-lookup.h"
diff --git a/gcc/cp/name-lookup.h b/gcc/cp/name-lookup.h
index 7172079b274..bac3fa71fc9 100644
--- a/gcc/cp/name-lookup.h
+++ b/gcc/cp/name-lookup.h
@@ -478,6 +478,7 @@ extern void push_to_top_level (void);
extern void pop_from_top_level (void);
extern void maybe_save_operator_binding (tree);
extern void push_operator_bindings (void);
+extern void push_using_decl_bindings (tree);
extern void discard_operator_bindings (tree);
/* Lower level interface for modules. */
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 100c35f053c..c27ef6d9fe0 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -18133,6 +18133,9 @@ tsubst_expr (tree t, tree args, tsubst_flags_t
complain, tree in_decl,
tree scope = USING_DECL_SCOPE (decl);
gcc_checking_assert (scope
== tsubst (scope, args, complain, in_decl));
+ /* We still need to push the bindings so that we can look up
+ this name later. */
+ push_using_decl_bindings (decl);
}
else if (is_capture_proxy (decl)
&& !DECL_TEMPLATE_INSTANTIATION (current_function_decl))
[Bug target/98657] [11 Regression] SVE: ICE (unrecognizable insn) with shift at -O3 -msve-vector-bits=256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98657 ktkachov at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P1 Last reconfirmed||2021-01-13 Status|UNCONFIRMED |NEW Known to work||10.2.1 Summary|SVE: ICE (unrecognizable|[11 Regression] SVE: ICE |insn) wtih shift at -O3 |(unrecognizable insn) with |-msve-vector-bits=256 |shift at -O3 ||-msve-vector-bits=256 CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug c++/98644] [10/11 Regression] [concepts] ICE in satisfaction_value, at cp/constraint.cc:2825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98644 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Patrick Palka --- (In reply to Patrick Palka from comment #1) > Confirmed. We started ICEing on the first testcase after r10-7361, and on > the second testcase after r11-5799. Previously, we would issue the fatal > error > > error: ‘reinterpret_cast(1)’ is not a constant expression > > during satisfaction (as per [temp.constr]/3). Oops, I meant to say [temp.constr.atomic]/3 here. Investigating.
[Bug fortran/78746] charlen_03, charlen_10 ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #28 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #27)
> At revision r11-6550 my instrumented compiler gives:
>
> pr78746.f90:5:40:
>
> 5 | character(:), allocatable :: x(n) ! { dg-error "must have a
> deferred shape" }
> |1
> Error: Allocatable component of structure at (1) must have a deferred shape
> =
> ==33829==ERROR: AddressSanitizer: heap-use-after-free on address
> 0x60400ee8 at pc 0x000100423feb bp 0x7ffeefbfe3b0 sp 0x7ffeefbfe3a8
> READ of size 8 at 0x60400ee8 thread T0
> ...
There's no testcase named "pr78746.f90" in the testsuite.
Would you please open a new PR with enough information?
[Bug c/98658] Loop idiom recognization for memcpy/memmove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98658
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Richard Biener ---
it's because
(gdb) p debug_data_dependence_relation (ddr)
(Data Dep:
#(Data Ref:
# bb: 3
# stmt: _1 = *s_19;
# ref: *s_19;
# base_object: *s_7(D);
# Access function 0: {0B, +, 4}_1
#)
#(Data Ref:
# bb: 3
# stmt: *d_18 = _1;
# ref: *d_18;
# base_object: *d_6(D);
# Access function 0: {0B, +, 4}_1
#)
(don't know)
)
and we say
/* Can't do memmove in case of unknown dependence or dependence without
classical distance vector. */
if (DDR_ARE_DEPENDENT (ddr) == chrec_dont_know
|| DDR_NUM_DIST_VECTS (ddr) == 0)
return;
which is because we need to check the depdenence is not backwards
(*s++ loads an earlier stored value). I don't see how that is
guaranteed in the 'copy' case and ICC either miscompiles this
or has a runtime check doing the memcpy only conditionally.
[Bug c++/98659] [11 Regression] ICE tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in maybe_instantiate_noexcept, at cp/pt.c:25445 since r11-6476-gaf362af18f405c34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98659 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/98659] [11 Regression] ICE tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in maybe_instantiate_noexcept, at cp/pt.c:25445 since r11-6476-gaf362af18f405c34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98659 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |11.0 Known to work||10.2.0 Last reconfirmed||2021-01-13 Ever confirmed|0 |1 Known to fail||11.0 Status|UNCONFIRMED |NEW
[Bug c++/98644] [10/11 Regression] [concepts] ICE in satisfaction_value, at cp/constraint.cc:2825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98644 Patrick Palka changed: What|Removed |Added Known to work||9.3.0 Known to fail||10.2.0, 11.0 Summary|[concepts] ICE in |[10/11 Regression] |satisfaction_value, at |[concepts] ICE in |cp/constraint.cc:2825 |satisfaction_value, at ||cp/constraint.cc:2825 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||ppalka at gcc dot gnu.org Target Milestone|--- |10.3 Last reconfirmed||2021-01-13 --- Comment #1 from Patrick Palka --- Confirmed. We started ICEing on the first testcase after r10-7361, and on the second testcase after r11-5799. Previously, we would issue the fatal error error: ‘reinterpret_cast(1)’ is not a constant expression during satisfaction (as per [temp.constr]/3).
[Bug c++/98659] New: [11 Regression] ICE tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in maybe_instantiate_noexcept, at cp/pt.c:25445 since r11-6476-gaf362af18f40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98659
Bug ID: 98659
Summary: [11 Regression] ICE tree check: expected tree that
contains ‘decl common’ structure, have ‘error_mark’ in
maybe_instantiate_noexcept, at cp/pt.c:25445 since
r11-6476-gaf362af18f405c34
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
Target Milestone: ---
The following is reduced from mkvtoolnix package:
$ cat reader.ii
template struct enable_if;
class function {
public:
template void operator=(_Functor);
};
class map {
public:
function operator[](int);
};
enum { avc_es };
template void do_probe();
template
typename enable_if::type do_probe();
void prober_for_type() {
map type_probe_map;
type_probe_map[avc_es] = do_probe;
}
$ g++ reader.ii -c
reader.ii: In substitution of ‘template void
function::operator=(_Functor) [with _Functor = ]’:
reader.ii:16:28: required from here
reader.ii:16:28: internal compiler error: tree check: expected tree that
contains ‘decl common’ structure, have ‘error_mark’ in
maybe_instantiate_noexcept, at cp/pt.c:25462
16 | type_probe_map[avc_es] = do_probe;
|^
0x8a7470 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.c:9984
0x71256f contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3452
0x71256f maybe_instantiate_noexcept(tree_node*, int)
/home/marxin/Programming/gcc/gcc/cp/pt.c:25462
0xb59cc9 resolve_overloaded_unification
/home/marxin/Programming/gcc/gcc/cp/pt.c:22386
0xb59cc9 unify_one_argument
/home/marxin/Programming/gcc/gcc/cp/pt.c:21932
0xb72005 type_unification_real
/home/marxin/Programming/gcc/gcc/cp/pt.c:22076
0xb81de9 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:21445
0x986a63 add_template_candidate_real
/home/marxin/Programming/gcc/gcc/cp/call.c:3441
0x98745c add_template_candidate
/home/marxin/Programming/gcc/gcc/cp/call.c:3526
0x98745c add_candidates
/home/marxin/Programming/gcc/gcc/cp/call.c:5955
0x989f99 add_candidates
/home/marxin/Programming/gcc/gcc/cp/call.c:5870
0x989f99 add_operator_candidates
/home/marxin/Programming/gcc/gcc/cp/call.c:6074
0x9915ef build_new_op_1
/home/marxin/Programming/gcc/gcc/cp/call.c:6282
0x992351 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
/home/marxin/Programming/gcc/gcc/cp/call.c:6670
0xbeff5c cp_build_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
int)
/home/marxin/Programming/gcc/gcc/cp/typeck.c:8695
0xbf08b8 build_x_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
int)
/home/marxin/Programming/gcc/gcc/cp/typeck.c:8957
0xaed67e cp_parser_assignment_expression
/home/marxin/Programming/gcc/gcc/cp/parser.c:10172
0xaef022 cp_parser_expression
/home/marxin/Programming/gcc/gcc/cp/parser.c:10298
0xaf2648 cp_parser_expression_statement
/home/marxin/Programming/gcc/gcc/cp/parser.c:11965
0xafe880 cp_parser_statement
/home/marxin/Programming/gcc/gcc/cp/parser.c:11761
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jonathan Wakely --- This should be fixed in all active branches now.
[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:283c218a4846075c549f0215d6883e577b26e845 commit r8-10726-g283c218a4846075c549f0215d6883e577b26e845 Author: Jonathan Wakely Date: Wed Jan 13 11:03:58 2021 + libstdc++: Fix clang analyzer suppression [PR 98605] The fix for PR libstdc++/82481 should only have applied for targets where _GLIBCXX_HAVE_TLS is defined. Because it was also done for non-TLS targets, it isn't possible to use clang's analyzers on non-TLS targets if the code uses . This fixes it by using a NOLINT comment on the relevant line instead of testing #ifdef __clang_analyzer__ and compiling different code when analyzing. I'm not actually able to reproduce the analyzer warning with the tools from Clang 10.0.1 so I'm not going to try to make the suppression more specific with NOLINTNEXTLINE(clang-analyzer-code.StackAddressEscape). libstdc++-v3/ChangeLog: PR libstdc++/98605 * include/std/mutex (call_once): Use NOLINT to suppress clang analyzer warnings. (cherry picked from commit 8d3636923a309074eb19240ebaa30c1a0801eaaf)
[Bug libstdc++/82481] dangling reference in mutex:693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82481 --- Comment #13 from CVS Commits --- The releases/gcc-8 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:283c218a4846075c549f0215d6883e577b26e845 commit r8-10726-g283c218a4846075c549f0215d6883e577b26e845 Author: Jonathan Wakely Date: Wed Jan 13 11:03:58 2021 + libstdc++: Fix clang analyzer suppression [PR 98605] The fix for PR libstdc++/82481 should only have applied for targets where _GLIBCXX_HAVE_TLS is defined. Because it was also done for non-TLS targets, it isn't possible to use clang's analyzers on non-TLS targets if the code uses . This fixes it by using a NOLINT comment on the relevant line instead of testing #ifdef __clang_analyzer__ and compiling different code when analyzing. I'm not actually able to reproduce the analyzer warning with the tools from Clang 10.0.1 so I'm not going to try to make the suppression more specific with NOLINTNEXTLINE(clang-analyzer-code.StackAddressEscape). libstdc++-v3/ChangeLog: PR libstdc++/98605 * include/std/mutex (call_once): Use NOLINT to suppress clang analyzer warnings. (cherry picked from commit 8d3636923a309074eb19240ebaa30c1a0801eaaf)
[Bug c++/98641] Feature request: implement pointer alignment builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98641 --- Comment #8 from Alex Richardson --- (In reply to Jakub Jelinek from comment #3) > I guess I have big questions on what exactly will it do during constexpr > evaluation - if it is on a pointer to object with certain alignment, for > smaller alignment arguments guess it is just like pointer arithmetics then, > but if it asks for larger alignment, shall it make it non-constant > expression? When I implemented this for clang, I made the expression no longer constant if __builtin_is_aligned() cannot be evaluated to true (since it might actually be true at run time). Therefore the following gives a "non a constant expression error rather than returning false": extern int x; _Static_assert(__builtin_is_aligned(, 8), ""); See https://github.com/llvm/llvm-project/commit/8c387cbea76b169f1f8ecc7693797e96567ed896#diff-b69ce3cbe3c48b9fac72f4c22fe7bb425c8757b144a87c44347ff1522360460fR211
[Bug tree-optimization/98597] [11 Regression] ICE in print_mem_ref since r11-6508-gabb1b6058c09a7c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98597 --- Comment #10 from Jakub Jelinek --- BTW, I'm not convinced it is ok to use TREE_TYPE (TREE_TYPE arg)) in the !addr case for anything at all even for warnings, as in GIMPLE pointer conversions are useless and therefore it very well could be completely unrelated pointer type (in the more lucky case say void * from say the memory allocation, but if less lucky...).
[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4aeae11db66c9bce0aadf447e6ff0776a97bfccf commit r9-9180-g4aeae11db66c9bce0aadf447e6ff0776a97bfccf Author: Jonathan Wakely Date: Wed Jan 13 11:03:58 2021 + libstdc++: Fix clang analyzer suppression [PR 98605] The fix for PR libstdc++/82481 should only have applied for targets where _GLIBCXX_HAVE_TLS is defined. Because it was also done for non-TLS targets, it isn't possible to use clang's analyzers on non-TLS targets if the code uses . This fixes it by using a NOLINT comment on the relevant line instead of testing #ifdef __clang_analyzer__ and compiling different code when analyzing. I'm not actually able to reproduce the analyzer warning with the tools from Clang 10.0.1 so I'm not going to try to make the suppression more specific with NOLINTNEXTLINE(clang-analyzer-code.StackAddressEscape). libstdc++-v3/ChangeLog: PR libstdc++/98605 * include/std/mutex (call_once): Use NOLINT to suppress clang analyzer warnings. (cherry picked from commit 8d3636923a309074eb19240ebaa30c1a0801eaaf)
[Bug libstdc++/82481] dangling reference in mutex:693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82481 --- Comment #12 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4aeae11db66c9bce0aadf447e6ff0776a97bfccf commit r9-9180-g4aeae11db66c9bce0aadf447e6ff0776a97bfccf Author: Jonathan Wakely Date: Wed Jan 13 11:03:58 2021 + libstdc++: Fix clang analyzer suppression [PR 98605] The fix for PR libstdc++/82481 should only have applied for targets where _GLIBCXX_HAVE_TLS is defined. Because it was also done for non-TLS targets, it isn't possible to use clang's analyzers on non-TLS targets if the code uses . This fixes it by using a NOLINT comment on the relevant line instead of testing #ifdef __clang_analyzer__ and compiling different code when analyzing. I'm not actually able to reproduce the analyzer warning with the tools from Clang 10.0.1 so I'm not going to try to make the suppression more specific with NOLINTNEXTLINE(clang-analyzer-code.StackAddressEscape). libstdc++-v3/ChangeLog: PR libstdc++/98605 * include/std/mutex (call_once): Use NOLINT to suppress clang analyzer warnings. (cherry picked from commit 8d3636923a309074eb19240ebaa30c1a0801eaaf)
[Bug c++/98625] UBSAN: gcc/cp/module.cc:977:15: runtime error: left shift of negative value -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98625 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Nathan Sidwell --- magic configure: --with-build-config=bootstrap-ubsan
[Bug tree-optimization/98597] [11 Regression] ICE in print_mem_ref since r11-6508-gabb1b6058c09a7c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98597
--- Comment #9 from Jakub Jelinek ---
That would be then following (though I didn't want to touch the rest of
print_mem_ref so the patch doesn't remember op anywhere and resets byte_off
too).
--- gcc/c-family/c-pretty-print.c.jj2021-01-13 08:02:09.425498954 +0100
+++ gcc/c-family/c-pretty-print.c 2021-01-13 15:02:57.860329998 +0100
@@ -1809,6 +1809,113 @@ pp_c_call_argument_list (c_pretty_printe
pp_c_right_paren (pp);
}
+/* Try to fold *(type *) into op.fld.fld2[1] if possible.
+ Only used for printing expressions. Should punt if ambiguous
+ (e.g. in unions). */
+
+static tree
+c_fold_indirect_ref_for_warn (location_t loc, tree type, tree op,
+ offset_int )
+{
+ tree optype = TREE_TYPE (op);
+ if (off == 0)
+{
+ if (lang_hooks.types_compatible_p (optype, type))
+ return op;
+ /* *(foo *) => __real__ complexfoo */
+ else if (TREE_CODE (optype) == COMPLEX_TYPE
+ && lang_hooks.types_compatible_p (type, TREE_TYPE (optype)))
+ return build1_loc (loc, REALPART_EXPR, type, op);
+}
+ /* ((foo*))[1] => __imag__ complexfoo */
+ else if (TREE_CODE (optype) == COMPLEX_TYPE
+ && lang_hooks.types_compatible_p (type, TREE_TYPE (optype))
+ && tree_to_uhwi (TYPE_SIZE_UNIT (type)) == off)
+{
+ off = 0;
+ return build1_loc (loc, IMAGPART_EXPR, type, op);
+}
+ /* ((foo *))[x] => fooarray[x] */
+ if (TREE_CODE (optype) == ARRAY_TYPE
+ && TYPE_SIZE_UNIT (TREE_TYPE (optype))
+ && TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (optype))) == INTEGER_CST
+ && !integer_zerop (TYPE_SIZE_UNIT (TREE_TYPE (optype
+{
+ tree type_domain = TYPE_DOMAIN (optype);
+ tree min_val = size_zero_node;
+ if (type_domain && TYPE_MIN_VALUE (type_domain))
+ min_val = TYPE_MIN_VALUE (type_domain);
+ offset_int el_sz = wi::to_offset (TYPE_SIZE_UNIT (TREE_TYPE (optype)));
+ offset_int idx = off / el_sz;
+ offset_int rem = off % el_sz;
+ if (TREE_CODE (min_val) == INTEGER_CST)
+ {
+ tree index
+ = wide_int_to_tree (sizetype, idx + wi::to_offset (min_val));
+ op = build4_loc (loc, ARRAY_REF, TREE_TYPE (optype), op, index,
+ NULL_TREE, NULL_TREE);
+ off = rem;
+ if (tree ret = c_fold_indirect_ref_for_warn (loc, type, op, off))
+ return ret;
+ return op;
+ }
+}
+ /* ((foo *)_with_foo_field)[x] => COMPONENT_REF */
+ else if (TREE_CODE (optype) == RECORD_TYPE)
+{
+ for (tree field = TYPE_FIELDS (optype);
+ field; field = DECL_CHAIN (field))
+ if (TREE_CODE (field) == FIELD_DECL
+ && TREE_TYPE (field) != error_mark_node
+ && TYPE_SIZE_UNIT (TREE_TYPE (field))
+ && TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (field))) == INTEGER_CST)
+ {
+ tree pos = byte_position (field);
+ if (TREE_CODE (pos) != INTEGER_CST)
+ continue;
+ offset_int upos = wi::to_offset (pos);
+ offset_int el_sz
+ = wi::to_offset (TYPE_SIZE_UNIT (TREE_TYPE (field)));
+ if (upos <= off && off < upos + el_sz)
+ {
+ tree cop = build3_loc (loc, COMPONENT_REF, TREE_TYPE (field),
+ op, field, NULL_TREE);
+ off = off - upos;
+ if (tree ret = c_fold_indirect_ref_for_warn (loc, type, cop,
+off))
+ return ret;
+ return cop;
+ }
+ }
+}
+ /* Similarly for unions, but in this case try to be very conservative,
+ only match if some field has type compatible with type and it is the
+ only such field. */
+ else if (TREE_CODE (optype) == UNION_TYPE)
+{
+ tree fld = NULL_TREE;
+ for (tree field = TYPE_FIELDS (optype);
+ field; field = DECL_CHAIN (field))
+ if (TREE_CODE (field) == FIELD_DECL
+ && TREE_TYPE (field) != error_mark_node
+ && lang_hooks.types_compatible_p (TREE_TYPE (field), type))
+ {
+ if (fld)
+ return NULL_TREE;
+ else
+ fld = field;
+ }
+ if (fld)
+ {
+ off = 0;
+ return build3_loc (loc, COMPONENT_REF, TREE_TYPE (fld), op, fld,
+NULL_TREE);
+ }
+}
+
+ return NULL_TREE;
+}
+
/* Print the MEM_REF expression REF, including its type and offset.
Apply casts as necessary if the type of the access is different
from the type of the accessed object. Produce compact output
@@ -1836,6 +1943,17 @@ print_mem_ref (c_pretty_printer *pp, tre
const bool addr = TREE_CODE (arg) == ADDR_EXPR;
if (addr)
{
+ tree op
+ = c_fold_indirect_ref_for_warn (EXPR_LOCATION (e), TREE_TYPE (e),
+
[Bug c/98658] Loop idiom recognization for memcpy/memmove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98658 --- Comment #1 from Dávid Bolvanský --- ICC produces memcpy: https://godbolt.org/z/oKxxTM
[Bug fortran/98638] [11 Regression] ICE: Segmentation fault (in lookup_page_table_entry) since r11-6411-gae99b315ba5b9e1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98638 --- Comment #6 from Martin Liška --- I see a similar ICE happening in libretro-mame package where a PCH is used: ../../../../../src/emu/screen.h: In member function 'std::enable_if_t::supports_callback::value, void> screen_device::set_screen_update(F&&, const char*) [with F = unsigned int (pacman_state::*)(screen_device&, bitmap_ind16&, const rectangle&)]': ../../../../../src/emu/screen.h:344:85: internal compiler error: Segmentation fault 344 | std::enable_if_t::value> set_screen_update(F &, const char *name) | ^ 0x1387176 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1], diagnostic_t) [clone .lto_priv.0] ???:0 0xe20f60 internal_error(char const*, ...) ???:0 0xb1c906 crash_signal(int) [clone .lto_priv.0] ???:0 0x8bfcde ggc_set_mark(void const*) [clone .cold] ???:0 0x1362a45 gt_ggc_mx_vec_edge_va_gc_(void*) ???:0 0x1362974 gt_ggc_mx_basic_block_def(void*) ???:0 0x1362499 gt_ggc_mx_gimple(void*) ???:0 0x13006d1 gt_ggc_mx_lang_tree_node(void*) ???:0 0x1300629 gt_ggc_mx_lang_tree_node(void*) ???:0 0x1300d3a gt_ggc_mx_lang_tree_node(void*) ???:0 0x8bc53b gt_ggc_mx_lang_tree_node(void*) [clone .cold] ???:0 0x13019b4 gt_ggc_mx_lang_tree_node(void*) ???:0 0x1300e35 gt_ggc_mx_lang_tree_node(void*) ???:0 0x1300d3a gt_ggc_mx_lang_tree_node(void*) ???:0 0x1300eff gt_ggc_mx_lang_tree_node(void*) ???:0 0x130108f gt_ggc_mx_lang_tree_node(void*) ???:0 0x13012c5 gt_ggc_mx_lang_tree_node(void*) ???:0 0x130193d gt_ggc_mx_lang_tree_node(void*) ???:0 0x1300fed gt_ggc_mx_lang_tree_node(void*) ???:0 0x1301005 gt_ggc_mx_lang_tree_node(void*) ???:0 Please submit a full bug report,
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #11 from Svante Signell --- ping?
[Bug c/98658] New: Loop idiom recognization for memcpy/memmove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98658
Bug ID: 98658
Summary: Loop idiom recognization for memcpy/memmove
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
void copy(int *__restrict__ d, int * s, __SIZE_TYPE__ sz) {
__SIZE_TYPE__ i;
for (i = 0; i < sz; i++) {
*d++ = *s++;
}
}
gcc emits call to memcpy.
void copy(int * d, int * s, __SIZE_TYPE__ sz) {
__SIZE_TYPE__ i;
for (i = 0; i < sz; i++) {
*d++ = *s++;
}
}
gcc could emit memmove, but currently does not:
https://godbolt.org/z/5n1rnh
[Bug tree-optimization/92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645 --- Comment #26 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:285fa338b06b804e72997c4d876ecf08a9c083af commit r11-6649-g285fa338b06b804e72997c4d876ecf08a9c083af Author: Richard Biener Date: Wed Jan 13 13:48:31 2021 +0100 tree-optimization/92645 - avoid harmful early BIT_FIELD_REF canonicalization This avoids canonicalizing BIT_FIELD_REF (a, , 0) to (T1)a on integer typed a. This confuses the vectorizer SLP matching. With this delayed to after vector lowering the testcase in PR92645 from Skia is now finally optimized to reasonable assembly. 2021-01-13 Richard Biener PR tree-optimization/92645 * match.pd (BIT_FIELD_REF to conversion): Delay canonicalization until after vector lowering. * gcc.target/i386/pr92645-7.c: New testcase. * gcc.dg/tree-ssa/ssa-fre-54.c: Adjust. * gcc.dg/pr69047.c: Likewise.
[Bug tree-optimization/92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #27 from Richard Biener --- Fixed.
[Bug tree-optimization/98597] [11 Regression] ICE in print_mem_ref since r11-6508-gabb1b6058c09a7c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98597
--- Comment #8 from Jakub Jelinek ---
So, before starting to fix all the bugs in the print_mem_ref routine, I think
we should add something like:
--- gcc/c-family/c-pretty-print.c.jj2021-01-13 08:02:09.425498954 +0100
+++ gcc/c-family/c-pretty-print.c 2021-01-13 14:31:34.048591447 +0100
@@ -1809,6 +1809,103 @@ pp_c_call_argument_list (c_pretty_printe
pp_c_right_paren (pp);
}
+/* Try to fold *(type *) into op.fld.fld2[1] if possible.
+ Only used for printing expressions. Should punt if ambiguous
+ (e.g. in unions). */
+
+static tree
+c_fold_indirect_ref_for_warn (location_t loc, tree type, tree op,
+ offset_int off)
+{
+ tree optype = TREE_TYPE (op);
+ if (off == 0)
+{
+ if (lang_hooks.types_compatible_p (optype, type))
+ return op;
+ /* Also handle conversion to an empty base class, which
+is represented with a NOP_EXPR. */
+ /* *(foo *) => __real__ complexfoo */
+ else if (TREE_CODE (optype) == COMPLEX_TYPE
+ && lang_hooks.types_compatible_p (type, TREE_TYPE (optype)))
+ return build1_loc (loc, REALPART_EXPR, type, op);
+}
+ /* ((foo*))[1] => __imag__ complexfoo */
+ else if (TREE_CODE (optype) == COMPLEX_TYPE
+ && lang_hooks.types_compatible_p (type, TREE_TYPE (optype))
+ && tree_to_uhwi (TYPE_SIZE_UNIT (type)) == off)
+return build1_loc (loc, IMAGPART_EXPR, type, op);
+ /* ((foo *))[x] => fooarray[x] */
+ if (TREE_CODE (optype) == ARRAY_TYPE
+ && TYPE_SIZE_UNIT (TREE_TYPE (optype))
+ && TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (optype))) == INTEGER_CST
+ && !integer_zerop (TYPE_SIZE_UNIT (TREE_TYPE (optype
+{
+ tree type_domain = TYPE_DOMAIN (optype);
+ tree min_val = size_zero_node;
+ if (type_domain && TYPE_MIN_VALUE (type_domain))
+ min_val = TYPE_MIN_VALUE (type_domain);
+ offset_int el_sz = wi::to_offset (TYPE_SIZE_UNIT (TREE_TYPE (optype)));
+ offset_int idx = off / el_sz;
+ offset_int rem = off % el_sz;
+ if (TREE_CODE (min_val) == INTEGER_CST)
+ {
+ tree index
+ = wide_int_to_tree (sizetype, idx + wi::to_offset (min_val));
+ op = build4_loc (loc, ARRAY_REF, TREE_TYPE (optype), op, index,
+ NULL_TREE, NULL_TREE);
+ return c_fold_indirect_ref_for_warn (loc, type, op, rem);
+ }
+}
+ /* ((foo *)_with_foo_field)[x] => COMPONENT_REF */
+ else if (TREE_CODE (optype) == RECORD_TYPE)
+{
+ for (tree field = TYPE_FIELDS (optype);
+ field; field = DECL_CHAIN (field))
+ if (TREE_CODE (field) == FIELD_DECL
+ && TREE_TYPE (field) != error_mark_node
+ && TYPE_SIZE_UNIT (TREE_TYPE (field))
+ && TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (field))) == INTEGER_CST)
+ {
+ tree pos = byte_position (field);
+ if (TREE_CODE (pos) != INTEGER_CST)
+ continue;
+ offset_int upos = wi::to_offset (pos);
+ offset_int el_sz
+ = wi::to_offset (TYPE_SIZE_UNIT (TREE_TYPE (field)));
+ if (upos <= off && off < upos + el_sz)
+ {
+ tree cop = build3_loc (loc, COMPONENT_REF, TREE_TYPE (field),
+ op, field, NULL_TREE);
+ if (tree ret = c_fold_indirect_ref_for_warn (loc, type, cop,
+off - upos))
+ return ret;
+ }
+ }
+}
+ /* Similarly for unions, but in this case try to be very conservative,
+ only match if some field has type compatible with type and it is the
+ only such field. */
+ else if (TREE_CODE (optype) == UNION_TYPE)
+{
+ tree fld = NULL_TREE;
+ for (tree field = TYPE_FIELDS (optype);
+ field; field = DECL_CHAIN (field))
+ if (TREE_CODE (field) == FIELD_DECL
+ && TREE_TYPE (field) != error_mark_node
+ && lang_hooks.types_compatible_p (TREE_TYPE (field), type))
+ {
+ if (fld)
+ return NULL_TREE;
+ else
+ fld = field;
+ }
+ if (fld)
+ return build3_loc (loc, COMPONENT_REF, TREE_TYPE (fld), op, fld,
+ NULL_TREE);
+}
+
+ return NULL_TREE;
+}
/* Print the MEM_REF expression REF, including its type and offset.
Apply casts as necessary if the type of the access is different
from the type of the accessed object. Produce compact output
@@ -1836,6 +1933,14 @@ print_mem_ref (c_pretty_printer *pp, tre
const bool addr = TREE_CODE (arg) == ADDR_EXPR;
if (addr)
{
+ tree op
+ = c_fold_indirect_ref_for_warn (EXPR_LOCATION (e), TREE_TYPE (e),
+ TREE_OPERAND (arg, 0), byte_off);
+ if (op)
+ {
+ pp->expression (op);
+ return;
+ }
arg = TREE_OPERAND (arg,
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 98626, which changed state. Bug 98626 Summary: UBSAN: vec.h:591:30: runtime error: member access within null pointer of type 'struct vec' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98626 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/98626] UBSAN: vec.h:591:30: runtime error: member access within null pointer of type 'struct vec'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98626 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Nathan Sidwell --- Fixed 11cbea852b0 2021-01-13 | c++: Fix cp_build_function_call_vec [PR 98626]
[Bug c++/98632] Warn about unspecified expression ordering for atomics with non-relaxed memory ordering.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98632
--- Comment #2 from tilps at hotmail dot com ---
*rough sketch*
class TaskConsumer {
void run() {
if (taken_count_.load(std::memory_order_acquire) <
task_count_.load(std::memory_order_acquire)) {
taken_count_.fetch_add(1, std::memory_order_acq_rel);
// ... handle the new task...
}
}
void addTask() {
task_count_.fetch_add(1, std::memory_order_acq_rel);
}
void reset() {
task_count_.store(0, std::memory_order_release);
taken_count_.store(0, std::memory_order_release);
}
std::atomic task_count_;
std::atomic taken_count_;
};
The above is not a 'complete' code sample, just illustrative.
One thread is calling 'run' in a loop.
Other thread calls reset, then add task some number of times. Waits until it
knows the first thread has done all tasks (not covered in the code above, but
assume that it is thread-safe and establishes acquire/release ordering as
appropriate), then calls reset again and repeats the process.
In order for the 'if' statement to behave correctly taken count must be read
before task count. If task count is read first it can read the value in
task_count_ before reset, but the taken_count_ value after reset.
If an optimizer (not necessarily an existing gcc one) decides to reorder the if
statement because the standard says order is unspecified and it notices that
task_count_ is an earlier memory address to taken_count_ and presumes
reordering might give a small performance increase due to sequential memory
access and cpu prefetching assumptions... then the code breaks.
Thus I would like a warning pointing at that if statement with wording along
the lines of:
C++ standard does not guarantee ordering of evaluation in this expression, thus
the order of atomic operations with non-relaxed memory ordering in this
expression is unspecified. Extract them into separate expressions to guarantee
that the ordering is consistent with the memory ordering annotations.
[Bug c++/98626] UBSAN: vec.h:591:30: runtime error: member access within null pointer of type 'struct vec'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98626 --- Comment #2 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:11cbea852b0ae2b0f17a9caeaf6344d689231c2f commit r11-6647-g11cbea852b0ae2b0f17a9caeaf6344d689231c2f Author: Nathan Sidwell Date: Wed Jan 13 05:13:12 2021 -0800 c++: Fix cp_build_function_call_vec [PR 98626] I misunderstood the cp_build_function_call_vec API, thinking a NULL vector was an acceptable way of passing no arguments. You need to pass a vector of no elements. PR c++/98626 gcc/cp/ * module.cc (module_add_import_initializers): Pass a zero-element argument vector.
[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8d3636923a309074eb19240ebaa30c1a0801eaaf commit r10-9267-g8d3636923a309074eb19240ebaa30c1a0801eaaf Author: Jonathan Wakely Date: Wed Jan 13 11:03:58 2021 + libstdc++: Fix clang analyzer suppression [PR 98605] The fix for PR libstdc++/82481 should only have applied for targets where _GLIBCXX_HAVE_TLS is defined. Because it was also done for non-TLS targets, it isn't possible to use clang's analyzers on non-TLS targets if the code uses . This fixes it by using a NOLINT comment on the relevant line instead of testing #ifdef __clang_analyzer__ and compiling different code when analyzing. I'm not actually able to reproduce the analyzer warning with the tools from Clang 10.0.1 so I'm not going to try to make the suppression more specific with NOLINTNEXTLINE(clang-analyzer-code.StackAddressEscape). libstdc++-v3/ChangeLog: PR libstdc++/98605 * include/std/mutex (call_once): Use NOLINT to suppress clang analyzer warnings.
[Bug libstdc++/82481] dangling reference in mutex:693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82481 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8d3636923a309074eb19240ebaa30c1a0801eaaf commit r10-9267-g8d3636923a309074eb19240ebaa30c1a0801eaaf Author: Jonathan Wakely Date: Wed Jan 13 11:03:58 2021 + libstdc++: Fix clang analyzer suppression [PR 98605] The fix for PR libstdc++/82481 should only have applied for targets where _GLIBCXX_HAVE_TLS is defined. Because it was also done for non-TLS targets, it isn't possible to use clang's analyzers on non-TLS targets if the code uses . This fixes it by using a NOLINT comment on the relevant line instead of testing #ifdef __clang_analyzer__ and compiling different code when analyzing. I'm not actually able to reproduce the analyzer warning with the tools from Clang 10.0.1 so I'm not going to try to make the suppression more specific with NOLINTNEXTLINE(clang-analyzer-code.StackAddressEscape). libstdc++-v3/ChangeLog: PR libstdc++/98605 * include/std/mutex (call_once): Use NOLINT to suppress clang analyzer warnings.
[Bug fortran/89204] -floop-interchange has no effect on Fortran code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89204 Richard Biener changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Richard Biener --- When interchange happens you should see sth like "loops interchanged in loop nest" when compiling with -fopt-info-loop. But it doesn't do that for the fortran case.
[Bug c++/98641] Feature request: implement pointer alignment builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98641 --- Comment #7 from Jakub Jelinek --- (In reply to Alex Richardson from comment #5) > extern int i; > _Static_assert(__builtin_is_aligned(__builtin_assume_aligned(, 16), 8), > ""); > generates an "alignment of the base pointee object (4 bytes) is less than > the asserted 16 byte" error when evaluating __builtin_assume_aligned(). in constant expression contexts perhaps, though I'd certainly not word it that way, if it was evaluated at runtime, it could have been true if one is lucky (or ensures it manually, e.g. by int alignas(16) i; at the variable definition).
[Bug c++/98641] Feature request: implement pointer alignment builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98641
--- Comment #6 from Alex Richardson
---
(In reply to Jakub Jelinek from comment #3)
> assume_aligned is something different, I guess __builtin_is_aligned expands
> to an actual runtime check (perhaps optimized away if the pointer can't be
> misaligned).
> So I guess __builtin_is_aligned (__builtin_assume_aligned (ptr, 32), 16)
> should optimize to true...
>
> I guess I have big questions on what exactly will it do during constexpr
> evaluation - if it is on a pointer to object with certain alignment, for
> smaller alignment arguments guess it is just like pointer arithmetics then,
> but if it asks for larger alignment, shall it make it non-constant
> expression?
Regarding your second question: If folding is possible during constant
evaluation, clang will fold it even at -O0. If it's unknown, the LLVM IR
optimization passes will attempt to fold it (taking into account
__builtin_assume_aligned metadata if present).
For example, in:
static inline _Bool is_aligned_wrapper(void* x) {
return __builtin_is_aligned(x, 4);
}
_Bool check_unknown(void* x) {
return is_aligned_wrapper(x);
}
_Bool check_known_4_byte_alignment(void) {
int i;
return is_aligned_wrapper();
}
_Bool check_assume_4_byte_alignment(void* x) {
return is_aligned_wrapper(__builtin_assume_aligned(x, 4));
}
The check_unknown() function will perform a run-time check, the other two
simply return true.
https://godbolt.org/z/v4Gaaj
