[Bug c/96606] Shift operator not working correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96606 RyuaNerin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from RyuaNerin --- Unsigned long int is 64bit integer in x64.
[Bug testsuite/96609] new test case gcc.dg/analyzer/init.c has many failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96609 seurer at gcc dot gnu.org changed: What|Removed |Added Host||powerpc64*-linux-gnu Target||powerpc64*-linux-gnu Build||powerpc64*-linux-gnu CC||bergner at gcc dot gnu.org, ||dmalcolm at gcc dot gnu.org --- Comment #1 from seurer at gcc dot gnu.org --- Also these: Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -fanalyzer -fdiagnostics-path-format=separate-events -Wanalyzer-too-complex -fanalyzer-call-summaries -S -o pr93032-mztools.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -fanalyzer -fdiagnostics-path-format=separate-events -Wanalyzer-too-complex -fanalyzer-call-summaries -S -o pr93032-mztools.s /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c: In function 'unzRepair': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: EN: 841-849 [-Wanalyzer-too-complex]
[Bug analyzer/93994] ICE in get_or_create_mem_ref, at analyzer/region-model.cc:6599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93994 --- Comment #1 from Arseny Solokha --- It is likely a duplicate of PR95152.
[Bug analyzer/93388] ensure -fanalyzer works with our C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93388 --- Comment #17 from Arseny Solokha --- (In reply to David Binderman from comment #16) > I had another look at this and considerable progress has been made. > Only six ices left for the C code in the test suite. These are After the recent analyzer overhaul it's probably time to update this list once again. Maybe trying each optimization level in turn besides -O2 might also make sense.
[Bug c/96610] ICE: in gimplify_va_arg_expr, at gimplify.c:15150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96610 Andrew Pinski changed: What|Removed |Added Summary|[11 Regression] ICE: in |ICE: in |gimplify_va_arg_expr, at|gimplify_va_arg_expr, at |gimplify.c:15150|gimplify.c:15150 Keywords||ice-checking, ||ice-on-invalid-code --- Comment #1 from Andrew Pinski --- >test.c:8: confused by earlier errors, bailing out It was ICEing in GCC 10, just with --enable-checking=release causes the above message to be printed out instead of a full ICE.
[Bug c/96610] New: [11 Regression] ICE: in gimplify_va_arg_expr, at gimplify.c:15150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96610
Bug ID: 96610
Summary: [11 Regression] ICE: in gimplify_va_arg_expr, at
gimplify.c:15150
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat test.c
void foo ( )
{
int x ;
int y[] = 1;
__builtin_va_arg ( x, int z );
}
---
$ gcc-snapshot11 --version
gcc (GCC) 11.0.0 20200802 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
---
$ gcc-snapshot11 test.c
test.c: In function ‘foo’:
test.c:6:15: error: invalid initializer
6 | int y[] = 1;
| ^
test.c:8:30: error: expected ‘)’ before ‘z’
8 | __builtin_va_arg ( x, int z );
| ^~
| )
test.c:8:27: error: first argument to ‘va_arg’ not of type ‘va_list’
8 | __builtin_va_arg ( x, int z );
| ^~~
test.c:8:27: internal compiler error: in gimplify_va_arg_expr, at
gimplify.c:15150
8 | __builtin_va_arg ( x, int z );
| ~~^
0x67c083 gimplify_va_arg_expr(tree_node**, gimple**, gimple**)
../../gcc-11-20200802/gcc/gimplify.c:15150
0xb12522 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-11-20200802/gcc/gimplify.c:13712
0xb15076 gimplify_stmt(tree_node**, gimple**)
../../gcc-11-20200802/gcc/gimplify.c:6822
0xb130eb gimplify_statement_list
../../gcc-11-20200802/gcc/gimplify.c:1856
0xb130eb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-11-20200802/gcc/gimplify.c:14082
0xb15076 gimplify_stmt(tree_node**, gimple**)
../../gcc-11-20200802/gcc/gimplify.c:6822
0xb15d41 gimplify_bind_expr
../../gcc-11-20200802/gcc/gimplify.c:1411
0xb1267d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-11-20200802/gcc/gimplify.c:13839
0xb2a797 gimplify_stmt(tree_node**, gimple**)
../../gcc-11-20200802/gcc/gimplify.c:6822
0xb2a797 gimplify_body(tree_node*, bool)
../../gcc-11-20200802/gcc/gimplify.c:14874
0xb2abcd gimplify_function_tree(tree_node*)
../../gcc-11-20200802/gcc/gimplify.c:15028
0x974437 cgraph_node::analyze()
../../gcc-11-20200802/gcc/cgraphunit.c:671
0x977477 analyze_functions
../../gcc-11-20200802/gcc/cgraphunit.c:1231
0x97803d symbol_table::finalize_compilation_unit()
../../gcc-11-20200802/gcc/cgraphunit.c:2987
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/96592] Tuple element w/ member reference to incomplete template type rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96592
John changed:
What|Removed |Added
CC||johnilacqua at hotmail dot com
--- Comment #1 from John ---
I was about to create a bug report for what appears to be the same issue.
Here's another simple reproducer:
#include
template
class DependsOnT
{
public:
DependsOnT(T&) {}
};
class Test
{
public:
Test() : test_{*this} {}
private:
std::tuple> test_;
};
It seems to depend entirely on the reference in the constructor of DependsOnT -
if I change that to a pointer it compiles without error.
[Bug analyzer/96598] false NULL argument warning [-Wanalyzer-null-argument]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96598 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Regression test added by above commit.
[Bug analyzer/96598] false NULL argument warning [-Wanalyzer-null-argument]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96598 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:2ec32ddf822887cddc8910ed30dc105890def4ee commit r11-2695-g2ec32ddf822887cddc8910ed30dc105890def4ee Author: David Malcolm Date: Thu Aug 13 15:11:10 2020 -0400 analyzer: add regression test [PR96598] PR analyzer/96598 reports that -fanalyzer issues a false warning: use of NULL 'str' where non-null expected with gcc 10.2 when used with -fsanitize=undefined. This was fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d. gcc/testsuite/ChangeLog: PR analyzer/96598 * gcc.dg/analyzer/pr96598.c: New test.
[Bug testsuite/96609] New: new test case gcc.dg/analyzer/init.c has many failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96609 Bug ID: 96609 Summary: new test case gcc.dg/analyzer/init.c has many failures Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:808f4dfeb3a95f50f15e71148e5c1067f90a126d, r11-2694 make -k check-gcc RUNTESTFLAGS=analyzer.exp=gcc.dg/analyzer/init.c Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -fanalyzer -fdiagnostics-path-format=separate-events -Wanalyzer-too-complex -fanalyzer-call-summaries -S -o init.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -fanalyzer -fdiagnostics-path-format=separate-events -Wanalyzer-too-complex -fanalyzer-call-summaries -S -o init.s /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c: In function 'test_1': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:30:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:31:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c: In function 'test_2': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:37:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:38:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c: In function 'test_3': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:44:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:45:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c: In function 'test_4': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:51:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:52:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c: In function 'test_5': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:58:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:59:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c: In function 'test_6': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:65:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:66:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c: In function 'test_7': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:72:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:73:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:74:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:75:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c: In function 'test_8': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:81:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:82:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:83:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:84:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c: In function 'test_9': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:90:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:91:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:92:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:93:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c: In function 'test_10': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:99:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:100:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:101:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:102:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c: In function 'test_11': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/init.c:108:3: warning: TRUE
[Bug analyzer/96608] New: Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 Bug ID: 96608 Summary: Build failure due to cast to type long on MinGW Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: markus.boeck02 at gmail dot com Target Milestone: --- Current trunk (revision 808f4dfeb3a95f50f15e71148e5c1067f90a126d) fails when using the MinGW target due to a few casts to the type long which is 32 bit on Windows. Following compiler errors appear: In file included from ../../gcc/analyzer/checker-path.cc:51: ../../gcc/analyzer/store.h: In member function 'hashval_t ana::symbolic_binding::hash() const': ../../gcc/analyzer/store.h:271:41: error: cast from 'const ana::region*' to 'long int' loses precision [-fpermissive] 271 | return (binding_key::impl_hash () ^ (long)m_region); | ^~ With the same error appearing roughly 10 times through the code base. Compiler used was GCC 10.2.1. Compilation command: x86_64-w64-mingw32-g++-10 -fno-PIE -c -fdebug-prefix-map=/mnt/c=C: -g -march=nehalem -O3 -I/mnt/c/GCC-Build/NewestLinux/Libraries/include -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -fno-common -DHAVE_CONFIG_H -I. -Ianalyzer -I../../gcc -I../../gcc/analyzer -I../../gcc/../include -I../../gcc/../libcpp/include -I/mnt/c/GCC-Build-Array/gcc/build-target-i686/./gmp -I/mnt/c/GCC-Build-Array/gcc/gmp -I/mnt/c/GCC-Build-Array/gcc/build-target-i686/./mpfr/src -I/mnt/c/GCC-Build-Array/gcc/mpfr/src -I/mnt/c/GCC-Build-Array/gcc/mpc/src -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace -I/mnt/c/GCC-Build-Array/gcc/build-target-i686/./isl/include -I/mnt/c/GCC-Build-Array/gcc/isl/include -I/mnt/c/GCC-Build/NewestLinux/Libraries/include -o analyzer/checker-path.o -MT analyzer/checker-path.o -MMD -MP -MF analyzer/.deps/checker-path.TPo ../../gcc/analyzer/checker-path.cc
[Bug libstdc++/54185] [4.7/4.8 Regression] condition_variable not properly destructed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185 --- Comment #15 from Jonathan Wakely --- (In reply to Lewis Hyatt from comment #14) > I have problems with the test case for this bug > (libstdc++-v3/testsuite/30_threads/condition_variable/54185.cc) failing > randomly. It fails reliably on AIX too. > I can submit this to gcc-patches if it makes sense to you? Thanks... Yes please, CCing the libstdc++ list.
[Bug libstdc++/54185] [4.7/4.8 Regression] condition_variable not properly destructed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gmail dot com
--- Comment #14 from Lewis Hyatt ---
Created attachment 49061
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49061=edit
Fix for random pthread_create() failures
Hello-
I have problems with the test case for this bug
(libstdc++-v3/testsuite/30_threads/condition_variable/54185.cc) failing
randomly. It happens more often with parallel make, and especially if running
the testsuite as a whole more than once in parallel. On my system at least
(x86-64, Ubuntu 18), it seems that pthread_create() will return EAGAIN
sometimes in any loop like the one this testcase uses:
for(int i = 0; i != 1000; ++i) {pthread_create(...); pthread_join(...);}
If such a loop is running in 3 or more processes in parallel it happens more
than 50% of the time. I am not sure what global resource gets used up, it
happens even if ulimit -a shows nothing being limited like processes or memory.
The attached patch fixes the failures for me; if thread creation fails, it just
gives up and moves on to the next iteration instead. I had to convert the
cond->wait() to the predicate form since it becomes possible for the notify to
take place prior to all threads calling wait.
I can submit this to gcc-patches if it makes sense to you? Thanks...
-Lewis
[Bug analyzer/94689] arrays of functions are not meaningful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94689 --- Comment #6 from pmatos at gcc dot gnu.org --- Thanks - I will rerun the static analyzer on the codebase that previously crashed the static analyzer and report back.
[Bug target/96536] -fcf-protection code in i386.md:restore_stack_nonlocal uses invalid compare-and-jump rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96536 Uroš Bizjak changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Last reconfirmed||2020-08-13 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #4 from Uroš Bizjak --- Created attachment 49060 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49060=edit Proposed patch Attached patch completely rewrites restore_stack_nonlocal expander. Can someone please test the patch on a CET enabled target?
[Bug target/96607] New: GCC feeds SPARC/Solaris linker with unrecognized TLS sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607
Bug ID: 96607
Summary: GCC feeds SPARC/Solaris linker with unrecognized TLS
sequences
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vita.batrla at gmail dot com
Target Milestone: ---
GCC generates invalid TLS sequences not understood by SPARC/Solaris linker so
resulting binary dumps core. The following example shows dump of .o file
containing TLS sequence that is not contiguous and uses register %i2 to hold
temporary value. See an example:
48: 35 00 00 00 sethi %hi(0), %i2
48: R_SPARC_TLS_GD_HI22 _ZSt15__once_callable
...
50: b4 06 a0 00 add %i2, 0, %i2
50: R_SPARC_TLS_GD_LO10 _ZSt15__once_callable
...
68: b4 05 c0 1a add %l7, %i2, %i2
68: R_SPARC_TLS_GD_ADD _ZSt15__once_callable
...
398: 40 00 00 00 call 398
<_ZNSt6thread11_State_implINS_8_InvokerISt5tupleIJZN4llvm10ThreadPoolC4EjEUlvE_E6_M_runEv+0x398>
398: R_SPARC_TLS_GD_CALL_ZSt15__once_callable
39c: 90 10 00 1a mov %i2, %o0
Per spec [1] GD TLS sequnce should be 4 instructions in this order:
General Dynamic Model Code Sequence Initial Relocation Symbol
0x00 sethi %hi(@dtlndx(x)), %o0 R_SPARC_TLS_GD_HI22 x
0x04 add %o0,%lo(@dtlndx(x)), %o0 R_SPARC_TLS_GD_LO10 x
0x08 add %l7,%o0, %o0 R_SPARC_TLS_GD_ADD x
0x0c call __tls_get_addr R_SPARC_TLS_GD_CALL x
With comment:
> The code sequence must appear in the code as is. It is not possible to move
> the second add instruction in the delay slot of the call instruction since
> the linker would not recognize the instruction sequence.
Solaris linker doesn't expect anything in the branch delay slot of the above
call instruction. An optimized sequence using a delay slot of call instruction
related to R_SPARC_TLS_GD_CALL relocation confuses the linker and causes it to
produce invalid code. Solaris linker in GD->IE translation replaces call
instruction by an 'add'. So the above example at offset 398 becomes: example by
> +0x398: call +0> add %g7, %o0, %o0
> +0x39c: mov %i2, %o0 > mov %i2, %o0
Before linking the "mov" instruction executes before "call" instruction (it is
in branch delay slot). After linking the 'mov' instruction executes in program
order, so the effect of 'add' instruction is lost and register %o0 value
becomes corrupted leading to SIGSEGV on dereference in best case.
3952 /* Return nonzero if TRIAL can go into the call delay slot. */
3953
3954 int
3955 eligible_for_call_delay (rtx_insn *trial)
3956 {
3957rtx pat;
3958
3959if (get_attr_in_branch_delay (trial) == IN_BRANCH_DELAY_FALSE)
3960 return 0;
3961
3962/* The only problematic cases are TLS sequences with Sun as/ld. */
3963if ((TARGET_GNU_TLS && HAVE_GNU_LD) || !TARGET_TLS)
3964 return 1;
3965
3966pat = PATTERN (trial);
3967
3968/* We must reject tgd_add{32|64}, i.e.
3969 (set (reg) (plus (reg) (unspec [(reg) (symbol_ref)]
UNSPEC_TLSGD)))
3970 and tldm_add{32|64}, i.e.
3971 (set (reg) (plus (reg) (unspec [(reg) (symbol_ref)]
UNSPEC_TLSLDM)))
3972 for Sun as/ld. */
3973if (GET_CODE (pat) == SET
3974&& GET_CODE (SET_SRC (pat)) == PLUS)
3975 {
3976rtx unspec = XEXP (SET_SRC (pat), 1);
3977
3978if (GET_CODE (unspec) == UNSPEC
3979 && (XINT (unspec, 1) == UNSPEC_TLSGD
3980 || XINT (unspec, 1) == UNSPEC_TLSLDM))
3981return 0;
3982 }
3983
3984return 1;
3985 }
3986
My hypothesis is that the block / check at line 3973 catches only 'add'
instructions in TLS sequence, but not if the TLS sequence calculates
a temporary value and stores it in register (intermediate code):
mov 'reg_with_temp_value', %o0 <-- eligible_for_call_delay() return 1
call R_SPARC_TLS_GD_CALL
the 'mov' bypasses branch delay slot eligibility check andcompiler produces .o:
call R_SPARC_TLS_GD_CALL
mov 'reg_with_temp_value', %o0
Then Solaris linker comes and optimizes GD -> IE like this:
add %g7, %o0, %o0
mov 'reg_with_temp_value', %o0
And breaks the binary. The check in eligible_for_call_delay() on line 3963
updated in [2] is fallen through as the gcc used in example above is compiled
to use GNU 'as' but Solaris linker. The decision whether the instruction is
eligible for delay slot is then taken by 3973, but that check unfortunately
handles simple cases only.
[1] https://www.uclibc.org/docs/tls.pdf
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93704
[Bug c/96606] Shift operator not working correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96606 --- Comment #1 from RyuaNerin --- Created attachment 49059 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49059=edit msvc vs gcc
[Bug c/96606] New: Shift operator not working correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96606 Bug ID: 96606 Summary: Shift operator not working correctly Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at ryuar dot in Target Milestone: --- Created attachment 49058 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49058=edit source code. Hello. The shift operator doesn't work correctly in some situations. Please check the attached file. after compiling with `gcc KISA_SEED_ECB.c`, The output below is shown. 9292920F 73870FC4 05D1ED04 182F3919 A = 9292920F >> 8 = C4929292 B = 73870FC4 >> 8 = 0F73870F I think the correct operation result is 9292920F 73870FC4 05D1ED04 182F3919 A = 9292920F >> 8 = 00929292 B = 73870FC4 >> 8 = 0073870F There seems to be a problem between line 353 and line 453. Please let me know if you think I'm mistaken.
[Bug analyzer/96598] false NULL argument warning [-Wanalyzer-null-argument]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96598 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-08-13 --- Comment #1 from David Malcolm --- Thanks for filing this bug. I can reproduce it, but it looks like I fixed it in g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). I'll close this out once I've added a regression test for it.
[Bug analyzer/95240] calloc() false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95240 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from David Malcolm --- Thanks for filing this bug. The leak false positive should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/95042] ICE in can_merge_p, at analyzer/region-model.cc:2053
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95042 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from David Malcolm --- The ICE should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug c++/96605] New: ICE on C++20 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96605
Bug ID: 96605
Summary: ICE on C++20 code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitri.gorokhovik at free dot fr
Target Milestone: ---
The following code:
#include
template concept Expression_Term = true;
template concept Array_Term = true;
template struct dictionary {};
template struct tuple {};
template struct flow_graph {};
template class node,
Expression_Term ... exps, Array_Term ... lhs, Array_Term ... rhs>
constexpr auto apply (flow_graph {},
tuple {},
tuple {}>)
{
return std::tuple ...> {};
};
produces this ICE: [version: g++ (GCC) 11.0.0 20200812 (experimental)]
g++ -o test-1 -std=c++2a -fconcepts-ts test-1.i
test-1.i: In function ‘constexpr auto apply(flow_graph{},
tuple{}, tuple{}>)’:
test-1.i:11511:42: internal compiler error: in tsubst, at cp/pt.c:15388
11511 | return std::tuple ...> {};
| ^
0x688eab tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:15388
0xa101d6 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../src/gcc/cp/pt.c:29159
0xa39d02 convert_template_argument
../../src/gcc/cp/pt.c:8428
0xa3ca43 coerce_template_parms
../../src/gcc/cp/pt.c:8932
0xa285a8 lookup_template_class_1
../../src/gcc/cp/pt.c:9710
0xa2a0fc lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../src/gcc/cp/pt.c:10140
0xa641ab finish_template_type(tree_node*, tree_node*, int)
../../src/gcc/cp/semantics.c:3446
0x9ddb51 cp_parser_template_id
../../src/gcc/cp/parser.c:16833
0x9ddd43 cp_parser_class_name
../../src/gcc/cp/parser.c:23811
0x9d9c65 cp_parser_qualifying_entity
../../src/gcc/cp/parser.c:6844
0x9d9c65 cp_parser_nested_name_specifier_opt
../../src/gcc/cp/parser.c:6526
0x9e2815 cp_parser_simple_type_specifier
../../src/gcc/cp/parser.c:18229
0x9c642d cp_parser_type_specifier
../../src/gcc/cp/parser.c:17887
0x9dc143 cp_parser_type_specifier_seq
../../src/gcc/cp/parser.c:22493
0x9d4e54 cp_parser_type_id_1
../../src/gcc/cp/parser.c:22310
0x9d78e3 cp_parser_template_type_arg
../../src/gcc/cp/parser.c:22401
0x9dc2bf cp_parser_template_argument
../../src/gcc/cp/parser.c:17283
0x9dc2bf cp_parser_template_argument_list
../../src/gcc/cp/parser.c:17194
0x9dc2bf cp_parser_enclosed_template_argument_list
../../src/gcc/cp/parser.c:29886
0x9dd620 cp_parser_template_id
../../src/gcc/cp/parser.c:16766
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug analyzer/95026] "leak of FILE" false positive [CWE-775] [-Wanalyzer-file-leak]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95026 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from David Malcolm --- The leak false positive should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/94858] False report of memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94858 Bug 94858 depends on bug 94839, which changed state. Bug 94839 Summary: False positive with -fanalyzer and direct field assignment from calloc https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94839 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug analyzer/94839] False positive with -fanalyzer and direct field assignment from calloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94839 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- The leak false positive should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/94689] arrays of functions are not meaningful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94689 David Malcolm changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from David Malcolm --- The bogus "arrays of functions are not meaningful" error from -fanalyzer should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/94688] ICE caused by analyzer since r10-7502-ga96f1c38a787fbc8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94688 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- The ICE should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/94503] ICE on C++ return-value-optimization (in saved_diagnostic, at analyzer/diagnostic-manager.cc:84)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94503 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from David Malcolm --- The ICE (on C++ return-value-optimization) should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/94640] false-positive leaking FILE pointer assigned to function passed pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94640 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from David Malcolm --- The leak false positive should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/94839] False positive with -fanalyzer and direct field assignment from calloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94839 Bug 94839 depends on bug 94640, which changed state. Bug 94640 Summary: false-positive leaking FILE pointer assigned to function passed pointer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94640 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug analyzer/94458] -Wanalyzer-malloc-leak false positive when returning a heap-allocated struct by value holding a heap-allocated pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94458 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- The leak false positive should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/94399] analyzer reports false positives for stuff freed using __attribute__((cleanup()))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94399 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED CC||dmalcolm at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from David Malcolm --- The leak false positive should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/94011] ICE in validate, at analyzer/region-model.cc:3727
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94011 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from David Malcolm --- The ICE should be fixed by 808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/93938] ICE in validate, at analyzer/region-model.cc:231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93938 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from David Malcolm --- The ICE should be fixed by 808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/93032] analyzer fails to detect FILE * leak in zlib/contrib/minizip/mztools.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93032 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- The missing leak diagnostics should be fixed by 808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug tree-optimization/96603] Failure to optimize memcmp out for more than one byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96603 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 12086. *** This bug has been marked as a duplicate of bug 12086 ***
[Bug middle-end/12086] memcmp(i,j,4) should use word (SI) subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12086 Andrew Pinski changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment #17 from Andrew Pinski --- *** Bug 96603 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/96603] Failure to optimize memcmp out for more than one byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96603 Martin Sebor changed: What|Removed |Added Last reconfirmed||2020-08-13 CC||msebor at gcc dot gnu.org Keywords||missed-optimization Status|UNCONFIRMED |NEW Severity|normal |enhancement Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- I've been thinking about this transformation, not just for sizes of 2 but for larger objects as well. Looks like Clang 5 and later implements it for powers 2 up to 16 and does something slightly more involved for other small sizes of 10 bytes and less.
[Bug tree-optimization/96601] Failure to optimize equality comparison involving strstr to strlen+strncmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96601
Martin Sebor changed:
What|Removed |Added
Blocks||83819
Ever confirmed|0 |1
Last reconfirmed||2020-08-13
Severity|normal |enhancement
CC||msebor at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #1 from Martin Sebor ---
Sounds like a good idea. In fact, there is code to "Try to fold strstr (s, t)
eq/ne s to strncmp (s, t, strlen (t)) eq/ne 0" in tree-ssa-streln.c but it
triggers only when the length of the second argument has already been computed:
$ cat pr96601.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout pr96601.c
int f (const char *a, const char *b)
{
if (__builtin_strlen (b) > 1)
return __builtin_strstr (a, b) == a;
return -1;
}
;; Function f (f, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=0)
Removing basic block 5
f (const char * a, const char * b)
{
long unsigned int _1;
char * _2;
_Bool _3;
int _4;
int _8;
int _10;
[local count: 1073741824]:
_1 = __builtin_strlen (b_6(D));
if (_1 > 1)
goto ; [42.57%]
else
goto ; [57.43%]
[local count: 457091896]:
_10 = __builtin_strncmp (a_7(D), b_6(D), _1);
_3 = _10 == 0;
_8 = (int) _3;
[local count: 1073741824]:
# _4 = PHI <_8(3), -1(2)>
return _4;
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations
[Bug target/96506] ICE when using an MMA type as a function param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96506 --- Comment #2 from CVS Commits --- The master branch has been updated by Peter Bergner : https://gcc.gnu.org/g:0ad7e730c142ef6cd0ddc1491a89a7f330caa887 commit r11-2692-g0ad7e730c142ef6cd0ddc1491a89a7f330caa887 Author: Peter Bergner Date: Thu Aug 13 13:40:39 2020 -0500 rs6000: ICE when using an MMA type as a function param or return value [PR96506] PR96506 shows a problem where we ICE on illegal usage, namely using MMA types for function arguments and return values. The solution is to flag these illegal usages as errors early, before we ICE. 2020-08-13 Peter Bergner gcc/ PR target/96506 * config/rs6000/rs6000-call.c (rs6000_promote_function_mode): Disallow MMA types as return values. (rs6000_function_arg): Disallow MMA types as function arguments. gcc/testsuite/ PR target/96506 * gcc.target/powerpc/pr96506.c: New test.
[Bug c++/96604] rejects-valid on befriending specialization of conversion function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96604 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Last reconfirmed||2020-08-13 Keywords||rejects-valid Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Thanks for the report.
[Bug c++/96604] New: rejects-valid on befriending specialization of conversion function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96604
Bug ID: 96604
Summary: rejects-valid on befriending specialization of
conversion function template
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
struct A { template operator T(); };
struct X {};
struct B { friend A::operator X(); };
Per [temp.mem]/5 and /6, I think this is supposed to perform template argument
deduction against the conversion function template and befriend operator T with
T = B.
Clang, EDG, and MSVC accept.
[Bug c/96571] Bad "set but not used" warning with _Generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96571 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2020-08-13 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 49057 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49057=edit gcc11-pr96571.patch Untested fix.
[Bug c++/93529] Implement P1009R2, Array size deduction in new-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93529 Marek Polacek changed: What|Removed |Added Blocks||88323 --- Comment #2 from Marek Polacek --- On this now. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323 [Bug 88323] implement C++20 language features.
[Bug c++/95599] [coroutines] destructor for temporary operand to co_yield expression called before end of full-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95599 Jonathan Wakely changed: What|Removed |Added CC||max at duempel dot org --- Comment #9 from Jonathan Wakely --- *** Bug 95491 has been marked as a duplicate of this bug. ***
[Bug c++/95491] coroutines: awaited temporaries are never destructed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95491 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jonathan Wakely --- I think this is a dup of PR 95599 *** This bug has been marked as a duplicate of bug 95599 ***
[Bug lto/95548] ice in tree_to_shwi, at tree.c:7321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95548 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:aa81d093bf26a263131ecc1add04e27274457bb9 commit r10-8625-gaa81d093bf26a263131ecc1add04e27274457bb9 Author: Jan Hubicka Date: Sat Jun 6 22:19:46 2020 +0200 Fix ICE in ODR enum streaming [PR95548] gcc/ChangeLog: 2020-06-06 Jan Hubicka PR lto/95548 * ipa-devirt.c (struct odr_enum_val): Turn values to wide_int. (ipa_odr_summary_write): Update streaming. (ipa_odr_read_section): Update streaming. gcc/testsuite/ChangeLog: 2020-06-06 Jan Hubicka * g++.dg/torture/pr95548.C: New test. (cherry picked from commit eca7a60bd24ebd91addd785e420a06d8f5086634)
[Bug middle-end/95757] [11 regression] missing warning in gcc.dg/Wstringop-overflow-25.c since r11-1517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95757 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org, ||vries at gcc dot gnu.org --- Comment #2 from seurer at gcc dot gnu.org --- After g:ebd203778cc56df61cc3434fa01e77b4bae26362, r11-2655 the line number of the error changed but it still remains: now: FAIL: gcc.dg/Wstringop-overflow-25.c pr92814 (test for warnings, line 378) before: FAIL: gcc.dg/Wstringop-overflow-25.c pr92814 (test for warnings, line 377) This occurs on all powerpc64 targets. commit ebd203778cc56df61cc3434fa01e77b4bae26362 Author: Tom de Vries Date: Fri Aug 7 08:59:04 2020 +0200
[Bug tree-optimization/96603] New: Failure to optimize memcmp out for more than one byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96603
Bug ID: 96603
Summary: Failure to optimize memcmp out for more than one byte
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(const void *s1, const void *s2)
{
return memcmp(s1, s2, 2);
}
This can be optimized to `loadbe16(s1) - loadbe16(s2)` (where loadbe16 is a
function that read a 16-bit big endian number). This transformation is done by
LLVM, but not by GCC.
[Bug tree-optimization/96599] Failure to optimize self-stpcpy to strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96599
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2020-08-13
CC||msebor at gcc dot gnu.org
Keywords||missed-optimization
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Blocks||83819
--- Comment #1 from Martin Sebor ---
Overlapping copies are undefined and GCC diagnoses those it detects with
-Wrestrict. GCC also transforms some undefined statements (such as some
exactly overlapping copies) into their reasonable but benign equivalent but
it's neither done consistently, nor under the control of an option to give
users a way to opt out (or choose some other transformation such as replace the
undefined statement with a trap). While such transformations aren't always
desirable, diagnosing the underlying bugs almost always is. The long term goal
we converged on in Manchester in 2018 is to a) provide an option to control
such transformations, and b) issue a diagnostic when undefined behavior is
detected.
$ gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout pr96599.c
pr96599.c: In function ‘f’:
pr96599.c:5:10: warning: ‘stpcpy’ source argument is the same as destination
[-Wrestrict]
5 | return stpcpy (a, a);
| ^
;; Function f (f, funcdef_no=0, decl_uid=1933, cgraph_uid=1, symbol_order=0)
f (char * a)
{
char * _4;
[local count: 1073741824]:
_4 = stpcpy (a_2(D), a_2(D)); [tail call]
return _4;
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations
[Bug ipa/96482] [10 Regression] Combination of -finline-small-functions and ipa-cp optimisations causes incorrect values being passed to a function since r279523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96482 --- Comment #23 from CVS Commits --- The releases/gcc-10 branch has been updated by Martin Liska : https://gcc.gnu.org/g:4a2371497e9bed64aa4f46169127f3ea8e32e726 commit r10-8618-g4a2371497e9bed64aa4f46169127f3ea8e32e726 Author: Martin Liska Date: Thu Aug 13 09:38:41 2020 +0200 ipa: fix ICE in get_default_value The patch aligns code with ipcp_bits_lattice::set_to_constant where we properly mask m_value with m_mask. The same should be done here. gcc/ChangeLog: PR ipa/96482 * ipa-cp.c (ipcp_bits_lattice::meet_with_1): Mask m_value with m_mask. gcc/testsuite/ChangeLog: PR ipa/96482 * gcc.dg/ipa/pr96482-2.c: New test. (cherry picked from commit f91770216eade83f068528c1e4f00e2ac3b23044)
[Bug fortran/93671] gfortran 8-10 ICE on intrinsic assignment to allocatable derived-type component of coarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93671 --- Comment #4 from CVS Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:e00464a5cb4214f5a5de4535de4f684a86aa10d5 commit r11-2689-ge00464a5cb4214f5a5de4535de4f684a86aa10d5 Author: Andre Vehreschild Date: Thu Aug 13 16:06:31 2020 +0200 Fix PR fortran/93671; ICE in reffing coarray alloc. comps. Fix an ICE when in a coarray an allocatable component had another allocatable component. gcc/fortran/ChangeLog: 2020-08-10 Andre Vehreschild PR fortran/93671 * trans-array.c (structure_alloc_comps): Keep caf-mode when applying to components; get the caf_token correctly for allocated scalar components. gcc/testsuite/ChangeLog: 2020-08-10 Andre Vehreschild PR fortran/93671 * gfortran.dg/coarray/pr93671.f90: New test.
[Bug c++/96602] New: Partial ordering is ambiguous with default function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96602
Bug ID: 96602
Summary: Partial ordering is ambiguous with default function
arguments
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Reduced from StackOverflow (https://stackoverflow.com/q/63390165/2069064):
template
constexpr int foo(int=0){
return 0;
}
template
constexpr int foo(int=0, Args&&... args)
{
return 1;
}
static_assert(foo() == 0);
gcc considers this call ambiguous.
However,
static_assert(foo(0) == 0);
succeeds. But the presence of an explicit argument shouldn't matter here.
Removing the leading, non-deduced T, gcc does accept:
constexpr int foo(int=0){
return 0;
}
template
constexpr int foo(int=0, Args&&... args)
{
return 1;
}
static_assert(foo() == 0);
even without the argument. So there's some interplay here.
[Bug target/96479] AArch64: return SIMD register with -mgeneral-regs-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96479 rsandifo at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2020-08-13 Status|RESOLVED|REOPENED Ever confirmed|0 |1 Resolution|FIXED |--- --- Comment #4 from rsandifo at gcc dot gnu.org --- Patch was reverted due to a glibc build failure. See https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551903.html
[Bug target/96600] __builtin_modfl returns incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600 Jakub Jelinek changed: What|Removed |Added URL||https://sourceware.org/bugz ||illa/show_bug.cgi?id=18031 Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #7 from Jakub Jelinek --- There is a glibc bug about this already for years, just hasn't been fixed yet: https://sourceware.org/bugzilla/show_bug.cgi?id=18031
[Bug target/96600] __builtin_modfl returns incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600 Jakub Jelinek changed: What|Removed |Added CC||amodra at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Even the j0 > 103 case is wrong. First of all, it is unclear where that 103 comes from, e.g. for the quad version it uses j0 > 111, i.e. two smaller than the 113 bit precision, but 103 is 3 smaller than 106. But more importantly, it assumes that such values have no fractional part, which is not given. E.g. the upper double could be 0x1.0p+110 and lower 0x1.0f0f0f0f0f0fp+30.
[Bug c/96597] valgrind error in do_hoist_insertion during O3 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96597 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #8 from Martin Liška --- I've got a fix for it.
[Bug target/96600] __builtin_modfl returns incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600
--- Comment #5 from Jakub Jelinek ---
Actually, I think this is a glibc bug rather than gcc, because the values
computed at compile time look right, rather than those at runtime.
Consider:
int e = 69;
int main() {
long double a =
-__builtin_ldexpl(1.9446689187403240306919491832695730985733566864714824565497322973045558e+00l,
e);
long double b =
-__builtin_ldexpl(1.9446689187403240306919491832695730985733566864714824565497322973045558e+00l,
69);
long double tmp1, tmp2;
long double aa = __builtin_modfl(a, );
long double bb = __builtin_modfl(b, );
long double c = __builtin_truncl(a);
long double d = __builtin_truncl(b);
__builtin_printf ("a %.34La %.16a %.16a\n", a, (double) a, (double) (a -
(double) a));
__builtin_printf ("b %.34La %.16a %.16a\n", b, (double) b, (double) (b -
(double) b));
__builtin_printf ("aa %.34La %.16a %.16a\n", aa, (double) aa, (double) (aa -
(double) aa));
__builtin_printf ("bb %.34La %.16a %.16a\n", bb, (double) bb, (double) (bb -
(double) bb));
__builtin_printf ("tmp1 %.34La %.16a %.16a\n", tmp1, (double) tmp1, (double)
(tmp1 - (double) tmp1));
__builtin_printf ("tmp2 %.34La %.16a %.16a\n", tmp2, (double) tmp2, (double)
(tmp2 - (double) tmp2));
__builtin_printf ("c %.34La %.16a %.16a\n", c, (double) c, (double) (c -
(double) c));
__builtin_printf ("d %.34La %.16a %.16a\n", d, (double) d, (double) (d -
(double) d));
return 0;
}
The tmp1, tmp2, c and d values should be the same, i.e. the integral part.
But only tmp2, c and d are the same,
-0x1.f1d5d27f89914ab920p+69
while tmp1 is -0x1.f1d5d27f89914ab920p+69.
c is truncl computed at runtime, and tmp1 is the integral part from modfl
computed at runtime, so they should be the same, but they are not.
Seems glibc for modfl in this case just uses the upper double mantissa bits and
ignores the lower double mantissa bits.
Please file against glibc.
truncl has:
hi = trunc (xh);
if (hi != xh)
{
/* The high part is not an integer; the low part does not
affect the result. */
xh = hi;
xl = 0;
}
else
{
/* The high part is a nonzero integer. */
lo = xh > 0 ? floor (xl) : ceil (xl);
xh = hi;
xl = lo;
ldbl_canonicalize_int (, );
}
i.e. if the double trunc of the highpart double is equal to the highpart double
(this case), it does another floor or ceil.
While the modfl code assumes that if the exponent is > 52 and smaller than 103,
the fractional part is the second double, which is wrong.
The (i1&0x7fffLL) in there is weird because there is
i1 &= 0x000fLL; earlier, so it could just test i1, but more
importantly, the } else { ... code assumes that the low double must have a
particular exponent (it could have any smaller than the higher exponent minus
50something).
[Bug c/96597] valgrind error in do_hoist_insertion during O3 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96597 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #7 from Martin Liška --- I'm working on that..
[Bug c/96597] valgrind error in do_hoist_insertion during O3 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96597 --- Comment #6 from David Binderman --- Created attachment 49056 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49056=edit C source code Reduced code attached.
[Bug target/90933] [nvptx] internal compiler error: RTL check: expected code 'const_int', have 'reg' in rtx_to_poly_int64, at rtl.h:2367
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90933 --- Comment #1 from Tom de Vries --- New behaviour for the test-case. Instead of ICE-ing, we have: ... /home/vries/nvptx/mainkernel-2/source-gcc/gcc/testsuite/gcc.dg/memcmp-1.c: In function 'test_strncmp_49_1':^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/testsuite/gcc.dg/memcmp-1.c:190:13: error: total size of local objects 12659529496391581745 exceeds maximum 9223372036854775296^M ...
[Bug target/90928] [9/10 Regression] [nvptx] internal compiler error: in instantiate_virtual_regs_in_insn, at function.c:1737
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90928 Tom de Vries changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tom de Vries --- Patch committed, marking resolved-fixed.
[Bug target/90928] [9/10 Regression] [nvptx] internal compiler error: in instantiate_virtual_regs_in_insn, at function.c:1737
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90928 Tom de Vries changed: What|Removed |Added Target Milestone|9.4 |11.0
[Bug target/96600] __builtin_modfl returns incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600 --- Comment #4 from Jakub Jelinek --- Printing the numbers in detail (for all of them the long double and the two double portions after that)): a -0x1.f1d5d27f89914ab924b2cd0995p+69 -0x1.f1d5d27f89915000p+69 0x1.51b6d34cbd9ac000p+15 b -0x1.f1d5d27f89914ab924b2cd0995p+69 -0x1.f1d5d27f89915000p+69 0x1.51b6d34cbd9ac000p+15 aa 0x1.51b6d34cbd9ac0p+15 0x1.51b6d34cbd9ac000p+15 0x0.p+0 bb -0x1.2cb3426540p-1 -0x1.2cb342654000p-1 0x0.p+0 tmp1 -0x1.f1d5d27f899150p+69 -0x1.f1d5d27f89915000p+69 0x0.5000p-1022 tmp2 -0x1.f1d5d27f89914ab920p+69 -0x1.f1d5d27f89915000p+69 0x1.51b8p+15 But e.g. __builtin_truncl works the same on both, I'll have a look in a debugger.
[Bug target/96600] __builtin_modfl returns incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600
--- Comment #3 from Matthias Kretz (Vir) ---
I should be more precise. Take this test case:
int e = 69;
int main() {
__ibm128 a = -__builtin_ldexpl(
1.9446689187403240306919491832695730985733566864714824565497322973045558e+00l,
e);
__ibm128 tmp;
__ibm128 aa = __builtin_modfl(a, );
if (aa >= 1) {
__builtin_printf("modfl: %Lf\n", aa);
__builtin_printf("copysign(x-trunc(x), x): %Lf\n", __builtin_copysignl(a -
__builtin_truncl(a), a));
return 1;
}
return 0;
}
it prints:
modfl: 43227.412695
copysign(x-trunc(x), x): -0.587305
[Bug tree-optimization/96601] New: Failure to optimize equality comparison involving strstr to strlen+strncmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96601
Bug ID: 96601
Summary: Failure to optimize equality comparison involving
strstr to strlen+strncmp
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
bool f(const char *a, const char *b)
{
return strstr(a, b) == a;
}
This can be optimized to `strncmp(a, b, strlen(b))`. This transformation is
done by LLVM, but not by GCC.
[Bug target/96600] __builtin_modfl returns incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600
--- Comment #2 from Matthias Kretz (Vir) ---
The runtime modf actually returns a large number. This is not about precision
but about completely bogus values. You can adjust the testcase to:
int e = 69;
int main() {
long double a = -__builtin_ldexpl(
1.9446689187403240306919491832695730985733566864714824565497322973045558e+00l,
e);
long double tmp;
long double aa = __builtin_modfl(a, );
if (aa >= 1) {
__builtin_abort();
}
}
[Bug target/96600] __builtin_modfl returns incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The testcase just assumes that modfl will be evaluated the same at compile time and at runtime, but for the broken by design double double format that is not the case. GCC internally treats the type as one with fixed 106 bit precision and that is why you get those results, while at runtime it actually is a variable bit precision (53 to 2000-ish mantissa bits) depending on the exact value.
[Bug testsuite/96589] Directive to redirect compiler output to /dev/null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96589
--- Comment #2 from Tom de Vries ---
With this patch:
...
diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-21.c
b/gcc/testsuite/gcc.dg/builtin-object-size-21.c
index 7e0f85ffdf3..87058988780 100644
--- a/gcc/testsuite/gcc.dg/builtin-object-size-21.c
+++ b/gcc/testsuite/gcc.dg/builtin-object-size-21.c
@@ -1,8 +1,7 @@
/* PR middle-end/92815 - spurious -Wstringop-overflow writing into
a flexible array of an extern struct
{ dg-do compile }
- { dg-options "-Wall -fdump-tree-optimized" }
- { dg-require-effective-target large_initializer } */
+ { dg-options "-Wall -fdump-tree-optimized -o /dev/null" } */
#define PTRDIFF_MAX __PTRDIFF_MAX__
...
we have:
...
spawn -ignore SIGHUP /home/vries/nvptx/mainkernel-2/build-gcc/gcc/xgcc
-B/home/vries/nvptx/mainkernel-2/build-gcc/gcc/
/home/vries/nvptx/mainkernel-2/source-gcc/gcc/testsuite/gcc.dg/builtin-object-size-21.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never
--sysroot=/home/vries/nvptx/mainkernel-2/install/nvptx-none -Wall
-fdump-tree-optimized -o /dev/null -S -isystem
/home/vries/nvptx/mainkernel-2/build-gcc/nvptx-none/./newlib/targ-include
-isystem /home/vries/nvptx/mainkernel-2/source-gcc/newlib/libc/include -o
builtin-object-size-21.s^M
cc1: error: output filename specified twice^M
compiler exited with status 1
FAIL: gcc.dg/builtin-object-size-21.c (test for errors, line 29)
...
[Bug c/96597] valgrind error in do_hoist_insertion during O3 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96597 Martin Liška changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Martin Liška --- Likely introduced with r11-2545-g1af5cdd77985daf76130f527deac425c43df9f49.
[Bug c++/96387] gnu gmp c source edit g++ internal compiler error appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96387 Andreas Schwab changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug target/96600] New: __builtin_modfl returns incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600
Bug ID: 96600
Summary: __builtin_modfl returns incorrect value
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Target: powerpc64le-*-*
Test case:
int e = 69;
int main() {
long double a = -__builtin_ldexpl(
1.9446689187403240306919491832695730985733566864714824565497322973045558e+00l,
e);
long double b = -__builtin_ldexpl(
1.9446689187403240306919491832695730985733566864714824565497322973045558e+00l,
69);
long double tmp;
long double aa = __builtin_modfl(a, );
long double bb = __builtin_modfl(b, );
if (aa != bb) {
if (a == b)
return 2;
else
return 1;
}
return 0;
}
This returns 2, i.e. the internal representation of a and b differ in such a
way that modf gets broken.
GCC was built with `--target=powerpc64le-linux-gnu --disable-nls
--without-headers --with-long-double-128`
[Bug c/96597] valgrind error in do_hoist_insertion during O3 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96597 --- Comment #4 from David Binderman --- Code seems ok on date 20200724, so someone has broken something recently.
[Bug c/96597] valgrind error in do_hoist_insertion during O3 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96597 --- Comment #3 from David Binderman --- Reduced command line: /home/dcb/gcc/working/./gcc/xgcc -B/home/dcb/gcc/working/./gcc/ -O2 -c Interestingly, -O3 not required. I'll have a look at previous versions of gcc then have a go at reducing the code.
[Bug ipa/96482] [10 Regression] Combination of -finline-small-functions and ipa-cp optimisations causes incorrect values being passed to a function since r279523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96482 --- Comment #22 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:f91770216eade83f068528c1e4f00e2ac3b23044 commit r11-2686-gf91770216eade83f068528c1e4f00e2ac3b23044 Author: Martin Liska Date: Thu Aug 13 09:38:41 2020 +0200 ipa: fix ICE in get_default_value The patch aligns code with ipcp_bits_lattice::set_to_constant where we properly mask m_value with m_mask. The same should be done here. gcc/ChangeLog: PR ipa/96482 * ipa-cp.c (ipcp_bits_lattice::meet_with_1): Mask m_value with m_mask. gcc/testsuite/ChangeLog: PR ipa/96482 * gcc.dg/ipa/pr96482-2.c: New test.
[Bug c/96597] valgrind error in do_hoist_insertion during O3 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96597 --- Comment #2 from David Binderman --- Created attachment 49055 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49055=edit gzipped C source code This attached file is preprocessed from libgcc/libgcov-driver.c. This line is required to compile it: /home/dcb/gcc/working/./gcc/xgcc -B/home/dcb/gcc/working/./gcc/ -B/home/dcb/gcc/results.20200812.valgrind/x86_64-pc-linux-gnu/bin/ -B/home/dcb/gcc/results.20200812.valgrind/x86_64-pc-linux-gnu/lib/ -isystem /home/dcb/gcc/results.20200812.valgrind/x86_64-pc-linux-gnu/include -isystem /home/dcb/gcc/results.20200812.valgrind/x86_64-pc-linux-gnu/sys-include-g -O3 -O2 -g -O3 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc -I../../../trunk.git/libgcc -I../../../trunk.git/libgcc/. -I../../../trunk.git/libgcc/../gcc -I../../../trunk.git/libgcc/../include -I../../../trunk.git/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -MT _gcov.o -MD -MP -MF _gcov.dep -DL_gcov -c
[Bug tree-optimization/96599] New: Failure to optimize self-stpcpy to strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96599
Bug ID: 96599
Summary: Failure to optimize self-stpcpy to strlen
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
char *f(char *a)
{
return stpcpy(a, a);
}
This can be optimized to `strlen(a) + a`. This transformation is done by LLVM,
but not by GCC.
[Bug c++/96387] gnu gmp c source edit g++ internal compiler error appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96387 cents2823 at yahoo dot co.jp changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #4 from cents2823 at yahoo dot co.jp --- Thank you for answering. >Did you recompile GCC, MPFR and mpc after this change? > If not then there is still no bug. I have uninstalled and installed g++, but have not recompiled MPFR and mpc. Does gmp struct change affect g++, MPFR, mpc? I found a procedure today that does not cause g++ errors. It's unclear why the new procedure shouldn't throw any errors. This bug report is resolved because the error can be avoided. Thanking you in advance. Frome:Tsukamoto Old procedure: #1 gnu gmp gmp-h.in 150 line __mpz_struct _mp_alloc int --> long int _mp_size int --> long int #2 gnu gmp gmp-h.in 188 line__mpf_struct _mp_prec int --> long int _mp_size int --> long int #3 gmp install(configure,make,make check,make install) #4 ln -nfs /usr/local/lib/libgmp.so.10.4.0 /usr/lib/x86_64-linux-gnu/libgmp.so.10 New procedure: %1 gnu gmp gmp-h.in 188 line__mpf_struct _mp_prec int --> long int _mp_size int --> long int %2 gmp install(configure,make,make check,make install) %3 ln -nfs /usr/local/lib/libgmp.so.10.4.0 /usr/lib/x86_64-linux- gnu/libgmp.so.10 %4 gnu gmp gmp-h.in 150 line __mpz_struct _mp_alloc int --> long int _mp_size int --> long int %5 gmp install(configure,make,make check,make install)
[Bug c/96597] valgrind error in do_hoist_insertion during O3 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96597 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-08-13 CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Can you please attached pre-processed source file?
[Bug fortran/96595] docs: typos in gfortran -fallow-argument-mismatch invoke description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96595 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Martin Liška --- Thank you for the patch.
[Bug fortran/96595] docs: typos in gfortran -fallow-argument-mismatch invoke description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96595 --- Comment #1 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:2b5490f5d1633fedf20e6eba87153c5963c61368 commit r11-2685-g2b5490f5d1633fedf20e6eba87153c5963c61368 Author: Matthew Krupcale Date: Thu Aug 13 09:44:42 2020 +0200 docs: Fix typos in -fallow-argument-mismatch description gcc/fortran/ChangeLog: PR fortran/96595 * invoke.texi: Fix typos.
[Bug c/96598] New: false NULL argument warning [-Wanalyzer-null-argument]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96598 Bug ID: 96598 Summary: false NULL argument warning [-Wanalyzer-null-argument] Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dpotapov at gmail dot com Target Milestone: --- Created attachment 49054 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49054=edit C code to demonstrate the problem A function receives an argument that is marked as non-NULL using __attribute__ ((__nonnull__ ())), and it uses this argument to invoke another function that also takes a non-NULL argument. The first invocation does NOT produce any warning as expected, but the second one does: test.c:67:9: warning: use of NULL ‘str’ where non-null expected [CWE-690] [-Wanalyzer-null-argument] It looks strange considering the argument has not changed anywhere in the function. Also, it looks like the warning is triggered by defining an unrelated local variable. The warning happens only when the source code is compiled with '-fanalyzer -fsanitize=undefined'. The attached C file demonstrates the problem.
[Bug c/96597] New: valgrind error in do_hoist_insertion during O3 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96597
Bug ID: 96597
Summary: valgrind error in do_hoist_insertion during O3 build
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
==62146== Conditional jump or move depends on uninitialised value(s)
==62146==at 0xD2A8FD: do_hoist_insertion (tree-ssa-pre.c:3581)
==62146==by 0xD2A8FD: insert (tree-ssa-pre.c:3685)
==62146==by 0xD2A8FD: (anonymous namespace)::pass_pre::execute(function*)
(tree-ssa-pre.c:4235)
tree-ssa-pre.c:3581 is
&& PRE_EXPR_REFERENCE (expr)->punned
Configure lines are
../trunk.git/configure --prefix=/home/dcb/gcc/results.20200812.valgrind \
--disable-bootstrap \
--disable-multilib \
--disable-werror \
--enable-checking=valgrind \
--enable-languages=c,c++,fortran
sed 's/-O2/-O3/' < Makefile > Makefile.tmp
mv Makefile.tmp Makefile
valgrind is version 3.16.0 and valgrind is configured as follows:
$ more ~/.valgrind*
::
/home/dcb32B/.valgrindrc
::
--suppressions=/home/dcb32B/.valgrind.supp
--expensive-definedness-checks=yes
::
/home/dcb32B/.valgrind.supp
::
{
bug1
Memcheck:Cond
fun:incorporate_penalties
}
